🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2191

Re: overloading global new and delete

#2191
From: Fergus Henderson
Date: Sat, 14 Oct 1995 15:57
63 lines
3296 bytes
avm@zilker.net (Alfredo V. Mendoza) writes:

>The program below was a testcase sent to IBM compiler defect group.
>The problem is when compiled with IBM  (413) xlC 3.1.2 , and ran
>the result is that the str() function in ostrstream  does NOT use
>the overloaded new but uses the IBM runtime new. And when the class
>is destroyed the memory that was allocated by str() is deleted by the
>user defined global delete. Which (IMHO) is wrong.

The `ostrstream' class is not part of the draft C++ standard.
The old `char *' based strstream classes have been replaced by
a new set of `string' based stringstream classes.

So I'm afraid the draft C++ standard doesn't say anything about
about the behaviour of ostrstream::str().

Incidentally, the global operator new in your example was not
strictly conforming C++.

>// overload global new
>//
>void* operator new(size_t size)
>{
>  void *p = malloc(size+sizeof(unsigned long));
>
>  unsigned long *p1 = (unsigned long*)p;	// get pointer to signpost
>  *p1 = 0xdeadbeef;				// set the signpost
>  p1++;										// set to start of user memory
>  cout << "new(" << size << ") : signpost = " << (void*)p
>	<< " : user = " << (void*)p1 << endl;
>  return((void*)p1);
>}

There is no guarantee that `p1' is suitably aligned here.
For example, this operator new will probably fail if you use it to
allocate a `double' on a SPARC, where doubles must be aligned
to 8-byte boundaries, but sizeof(long) == 4.

Another tricky issue is using `cout' in your global operator new.
Imagine what could happen if `ostream::operator<<' called your operator new:
your `::operator new' would call `ostream::operator<<', which could call
your `::operator new', which would call `ostream::operator<<', and so
on ... until stack overflow.

I think the current draft leaves it unspecified as to whether or not 
library functions will call a user-defined global operator new.

>IBM compiler development claims that when one uses their runtime
>classes, it will always use the IBM runtime new and delete regardless
>of an overloaded global new and delete.

I imagine that one reason they do that is precisely to avoid the
problem of infinite recursion described above.

-- 
Fergus Henderson             |  "Australia is the richest country in the world,
fjh@cs.mu.oz.au              |   according to a new system of measuring wealth
http://www.cs.mu.oz.au/~fjh  |   announced by the World Bank yesterday."
PGP: finger fjh@128.250.37.3 |  - Melbourne newspaper "The Age", 18 Sept 1995.

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID: <9528716.7351@mulga.cs.mu.OZ.AU>
Path: arc1-ca.pugleaf.net!engnews2.Eng.Sun.COM!taumet!clamage
References: <45js9r$iuq@hackberry.zilker.net>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!engnews2.Eng.Sun.COM!taumet!clamage
From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.std.c++
Subject: Re: overloading global new and delete
Date: 14 Oct 1995 15:57:24 GMT
Organization: Computer Science, University of Melbourne, Australia
Sender: news@cs.mu.OZ.AU (CS-Usenet)
Approved: clamage@eng.sun.com (comp.std.c++)
Message-ID: <9528716.7351@mulga.cs.mu.OZ.AU>
References: <45js9r$iuq@hackberry.zilker.net>
NNTP-Posting-Host: taumet.eng.sun.com
Originator: clamage@taumet