I just noticed that section 3.7.3.1 of CD2 seems to allow for the
possibility that all calls to operator new(0) yield the same pointer, an
implementation technique specifically prohibited by ARM 5.3.3.  Was this
prohibition really lifted?  Does the FDIS agree with CD2 in the regard?

Thanks,

Scott
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Scott Meyers <smeyers@aristeia.com> wrote:
: I just noticed that section 3.7.3.1 of CD2 seems to allow for the
: possibility that all calls to operator new(0) yield the same pointer, an
: implementation technique specifically prohibited by ARM 5.3.3.  Was this
: prohibition really lifted?  Does the FDIS agree with CD2 in the regard?

Hmm... Thanks for pointing this out. Seems to be that the prohibition
was indeed explicitly lifted. The footnote explicitly says that
this is done so that it is easier to implement operator new in terms
of malloc() and operator new[] in terms of calloc().
In C malloc(0) is implementation defined. On HP and Sun, for example,
malloc(0) = malloc(8) or something like that. On AIX malloc(0) = NULL.
The same footnote says that in C++ it can't be NULL. This is great,
because otherwize it might be impossible to tell
::operator new (0, nothrow) from out-of-memory condition. CD2 implicitly
says that ::operator delete(::operator new(0)) is fine, because applying
::operator delete() to anything returned by ::operator new() is fine.
Thus I see no problems with ::operator new(0) returning the same
pointer over and over again, as long as you can ::operator delete()
it over and over again, which is implicitly mandated. The possible
problems could appear if the equal pointers could point to different
complete objects (not subobjects of one another), but that's impossible
even with the relaxed wording, because a new expression would never ask
::operator new() for 0 bytes, because sizeof(complete object)
is always greater then 0. sizeof(incomplete object) can be equal
to zero.

class A {}; // sizeof(A) > 0
class B : public A {}; // sizeof(B::A) may be equal to zero.
                       // sizeof(B) > 0

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 02 Jan 98 00:13:30 GMT, Scott Meyers <smeyers@aristeia.com> wrote:

>I just noticed that section 3.7.3.1 of CD2 seems to allow for the
>possibility that all calls to operator new(0) yield the same pointer, an
>implementation technique specifically prohibited by ARM 5.3.3.  Was this
>prohibition really lifted?  Does the FDIS agree with CD2 in the regard?

Section 5.3.4 "New" para 7 says in a note that the pointers must be
distinct. (What was originally one section in the ARM was split among
three sections in the draft standard.) We ought to have normative text
saying so, however. Probably the place to add the requirement would be
in 18.4.1 "Storage allocation and deallocation". I've suggested that
we take this up as a clarification or technical corregendum after the
draft standard is accepted.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]