🚀 go-pugleaf

Hi,
G. Mike Butler D054 (mgb@kronecker.mitre.org) wrote:
: According to the ARM section 5.3.3:
:      "operator new() can be called with the argument
:       zero.  Repeated such calls return pointers to
:       distinct objects."  

: But when I execute the following:
:     #include <isotream.h>
:     main()
:     {
:       struct foo { char a[1024]; };
:       foo *p = new foo[0];
:       foo *q = new foo[0];

According to the DWP, 'new foo[x]' calls 'operator new[](y)' to
allocate the memory (see expr.new section 10 of the DWP) instead of
'operator new(y)'. This is a change over the ARM. Thus, I use 'operator
new[]()' in the discussion below.

Note, that this MIGHT call 'operator new[](0)' but might also call
'operator new[]()' with some different argument: The implementation is
allowed to store additional information, e.g. the number of objects
stored in the memory. If you want the check the values returned by
'operator new[]()' you have to call it directly, e.g.:

	void *ptr = operator new[](0);

... and release the memory allocated this way with 'operator delete[]()':

	operator delete[](ptr);

This mechanism is used to allocate "raw" (i.e. uninitialized) memory.
If you call 'new foo[x]' the compiler will invoke 'operator new[](y)'
according to the DWP. But it performs additional actions: It calls the
default ctor of 'foo' 'x' times to initialize the 'x' elements and
somehow remembers the 'x' to be used for later destruction when calling
'delete[] ...' (if it is necessary to remember the 'x').

:       cout << (void *)p << " " << (void *)q << endl;
:     }

: I get
:     0x338d8 0x338e8

: While these are distinct pointers, the pointers refer to overlapping
: objects. Is this a legitimate interpretation of section 5.3.3 or is
: this a compiler/library bug?

The problem is that you are mixing 'new foo[0]' and 'operator
new[](0)'.  The objects referred to in the description of 'operator
new()' in the ARM are of an arbitary type, e.g. 'char'.  Consider the
following fragment:

  void *ptr1 = operator new[](0);
  void *ptr2 = operator new[](0);

'ptr1' and 'ptr2' can indicate two adjacent bytes e.g 'ptr1 == 0x338d8'
and 'ptr2 == 0x338d9' (although I guess that it is unlikely that they
will do this). The requirement you cited rules out that 'ptr1' ==
'ptr2'.  I'm not sure whether this still applies to the rule found in
the DWP (It is not allowed to return a '0' pointer or to return a
pointer to or within currently allocated storage but it seems not to be
required to allocate any storage...).  The quote from the ARM does not
mean that 'new foo[0]' allocates enough storage to hold a 'foo' (this
was your interpretation of 'object').  It only means that two calls to
'new foo[0]' return two distinct pointers (without an intervening call
'delete'ing the object allocated with the first call to 'new foo[0]',
of course).

BTW, it results in undefined behavior to dereference the pointer
returned from a call to 'operator new(0)' or 'operator new[](0)'. The
exact rules an be found in section basic.stc.dynamic.allocation of the
DWP.

: Incidentally, the standard template library included with gcc 2.7.2
: relies on "operator new(0)" working.

I don't see where your example contradicts what is found in the ARM
or in the DWP.
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic


[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]