🚀 go-pugleaf

In article <9528716.7351@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> 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().

See Steve Clamage's posting.  (The exact text is in section D.3.1.2.)

|> 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.

You (and the original poster) also are forgetting what happens when
malloc returns NULL.

Of course, under Unix, the above is fully conforming even when malloc
returns NULL, since aborting the program with an error message (in
this case, `segment violation') is a legal response when no memory is
available:-).  (An interesting question: are user provided operator
new required to call the new_handler if no memory is present.  I
presume not.)

|> 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.

Which still doesn't make it legal.

The traditional way of handling this in C and Unix was to use setbuf.
Strictly speaking, however, I don't think that it is guaranteed that
this will work; cout could still dynamically allocate memory for other
reasons.  In practice, however, I suspect it will work.
--

James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung



[ 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. ]