home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / gnu / g / bug / 1842 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.4 KB
  1. Path: sparky!uunet!ogicse!emory!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!cmu.edu!court+
  2. From: court+@cmu.edu (Court Demas)
  3. Newsgroups: gnu.g++.bug
  4. Subject: Possible "new" bug
  5. Message-ID: <0f2GQY600Vom8jZ40U@andrew.cmu.edu>
  6. Date: 17 Nov 92 07:08:52 GMT
  7. Article-I.D.: andrew.0f2GQY600Vom8jZ40U
  8. Sender: gnulists@ai.mit.edu
  9. Distribution: gnu
  10. Organization: GNUs Not Usenet
  11. Lines: 26
  12. Approved: bug-g++@prep.ai.mit.edu
  13.  
  14. I have been wrestling with what seems to be a bug in g++ v2.2.2.  I am first
  15. assuming that the following two are equivalent:
  16.  
  17. Footype *f = new Footype();
  18.  
  19. and
  20.  
  21. Footype *f;
  22. f = new Footype();
  23. But these two fragments produce very different results (this is inside a
  24. function call).  The 1-line version behaves very badly - 'new' seems to
  25. reallocate a block of memory which was already allocated earlier in the
  26. application.  So, the object gets initialized ok, but it trashes a few other
  27. objects in the process.
  28.  
  29. I haven't been able to quantify this yet into a sample program, but I can
  30. definitely reproduce it in my application (it's 5k and 70 source files).
  31. I *never* deallocate memory in the application (all delete's are commented out)
  32. so I can't see why this should happen under any circumstances.
  33.  
  34. If anybody could provide an insight on this I would greatly appreciate it.
  35. I will hopefully be able to post a sample program which exhibits the bug soon.
  36.  
  37.  
  38. thanks,
  39. court
  40.