On Mon, 9 Feb 2004 03:26:12 +0000 (UTC), Stephen Clamage
<Stephen.Clamage@Sun.COM> wrote:

 > I read section 5.3.4 to say that the expression
 >       new T[0]
 > is ill-formed, for any type T. The standard requires a strictly
 > positive value for the constant-expression giving the array size. But
 > I tried a couple of compilers at full warning levels, and neither
 > complained about new char[0].

Maybe another read would help.  T[0] contains an expression which must
be non-negative.  The expression happens but is not required to be
constant.  T[0][5] is a form which requires the second expression to
be constant and positive.  Does that make sense?

John


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:
 >
 > James Kuyper <kuyper@saicmodis.com> wrote in message
 > news:<40240FCD.9A516495@saicmodis.com>...
 >
 > > 2. NULL can be an integer constant expression with a value of 0, cast
 > > to void* (this is not permitted in C++). In that case, malloc(NULL) is
 > > equivalent to malloc((void*)0), which in turn is equivalent to
 > > malloc((size_t)(void*)0). The result of (size_t)(void*)0 is
 > > implementation-defined; it can be any valid size_t value. On a great
 > > many implementations, it will be 0, but there are real implementations
 > > where it might not be, and portable code should not count on that.
 >
 > However, the conversion of ((void*)0) to an integral type requires an
 > explicit cast.  If this is the definition of NULL, then malloc(NULL)
 > should not compile.

More precisely, a diagnostic message is required, a fact that I forgot
to mention, in my haste to cover the NULL issue properly. However,
having issued that message, an implementation is free to continue with
translation and even execution of the program.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

lawrence.jones@ugsplm.com wrote:
 > In comp.std.c Stephen Clamage <Stephen.Clamage@sun.com> wrote:
 >
 >>Yes, and as I said, I don't see anything that prohibits always
 >>returning the same non-null address.
 >
 >
 > It says that malloc(0) behaves like, for example, malloc(1).  Do you
 > think that malloc(1) is allowed to return the same value all the time?
 >

I take your point, but I think there is a difference between malloc(0) and
malloc(1).

The expression malloc(1) returns a pointer to an object, whereas malloc(0) does
not. That is, there are no zero-sized objects, and you are not allowed to
dereference the result of malloc(0).

So I think the standard has a loophole that allows an implementation like I
suggested in another posting: Reserve one byte. Have malloc(0) return the
address of that byte, and have free() of that address do nothing. The returns
from malloc never point to any object that was not already free'd.

I'm not seriously recommending this approach. I just think that it doesn't
violate any requirement in the standard.

--
Steve Clamage, stephen.clamage@sun.com


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

>Stephen Clamage wrote:
>> Yes, and as I said, I don't see anything that prohibits always
>> returning the same non-null address.
>
>Since Standard C doesn't include 0-sized objects, if there
>is a successful malloc(0) in a conforming implementation,
>the associated object will occupy at least one byte,
>although a s.c. program isn't allowed to access it.
>It would be folly for an implementation to return a pointer
>to *the same* 0-sized region for multiple concurrent live
>allocations, because those allocations can be free()d and
>how then would it know when the last free() occurs (unless
>it adds the overhead of a reference count, which would have
>no other purpose).

Why would the implementation _care_ when the last free() occurs?

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steve Clamage wrote:
>
> lawrence.jones@ugsplm.com wrote:
>  > In comp.std.c Stephen Clamage <Stephen.Clamage@sun.com> wrote:
>  >
>  >>Yes, and as I said, I don't see anything that prohibits always
>  >>returning the same non-null address.
>  >
>  >
>  > It says that malloc(0) behaves like, for example, malloc(1).  Do you
>  > think that malloc(1) is allowed to return the same value all the time?
>  >
>
> I take your point, but I think there is a difference between malloc(0) and
> malloc(1).
>
> The expression malloc(1) returns a pointer to an object, whereas malloc(0) does
> not. That is, there are no zero-sized objects, and you are not allowed to
> dereference the result of malloc(0).

The standard specifies that the behavior of malloc(0), when it does not
return a null pointer, must be the same as the behavior of malloc(n) for
some non-zero value of n. That means it does return a pointer to an
object which is NOT zero-sized. It also says that it's illegal to
dereference the pointer to access that object. However, it's still
perfectly legal to use it for equality comparisons, and it must behave
with respect to those comparisons exactly like the result of malloc(n) -
which means it must compare unequal to any other pointer  returned by a
malloc(), unless one of the two pointer values being compared has been
passed to free(), in which case all bets are off.

Switching from issues of what the standard does say, to what it should
say: I think there's a fair amount of code out there written to call
malloc(size) for size values where you don't want to bother having
special handling for size==0, but where you do want to assume that each
non-null return value is unique. That doesn't seem to me to be an
unreasonable style of coding, given the current standard, and such code
would be broken if the standard were changed to allow malloc(0) to
always return the same non-null pointer value.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In comp.std.c Steve Clamage <Stephen.Clamage@sun.com> wrote:
 >
 > The expression malloc(1) returns a pointer to an object, whereas malloc(0) does
 > not. That is, there are no zero-sized objects, and you are not allowed to
 > dereference the result of malloc(0).

I don't agree with your conclusion -- malloc(0) most certainly *does*
return a pointer to an object.  Said object is not zero sized ("the
behavior is as if the size were some nonzero value"), but you are not
permitted to access it.

 > So I think the standard has a loophole that allows an implementation like I
 > suggested in another posting: Reserve one byte. Have malloc(0) return the
 > address of that byte, and have free() of that address do nothing. The returns
 > from malloc never point to any object that was not already free'd.

That does not meet the requirement that each allocation yield a pointer
to an object distinct from any other (live) object.

-Larry Jones

It's not denial.  I'm just very selective about the reality I accept.
-- Calvin


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steve Clamage <Stephen.Clamage@Sun.COM> wrote in message news:<c0gb3a$t28$1@news1nwk.SFbay.Sun.COM>...
 > The expression malloc(1) returns a pointer to an object, whereas malloc(0) does
 > not. That is, there are no zero-sized objects, and you are not allowed to
 > dereference the result of malloc(0).

No, malloc(0) either returns NULL or a pointer to an n-byte object,
for some unspecified nonzero n.  This object must be disjoint from any
other object.  You're not allowed to access the object, but you can
compare its address to addresses of other objects, and you can expect
them to turn out different.

 > So I think the standard has a loophole that allows an implementation like I
 > suggested in another posting: Reserve one byte. Have malloc(0) return the
 > address of that byte, and have free() of that address do nothing. The returns
 > from malloc never point to any object that was not already free'd.
 >
 > I'm not seriously recommending this approach. I just think that it doesn't
 > violate any requirement in the standard.

Except the one that it must be an object of a non-zero size, disjoint
from any other object.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In <c0gb3a$t28$1@news1nwk.SFbay.Sun.COM> Steve Clamage <Stephen.Clamage@Sun.COM> writes:


 >So I think the standard has a loophole that allows an implementation like I
 >suggested in another posting: Reserve one byte. Have malloc(0) return the
 >address of that byte, and have free() of that address do nothing. The returns
 >from malloc never point to any object that was not already free'd.
 >
 >I'm not seriously recommending this approach. I just think that it doesn't
 >violate any requirement in the standard.

It does:

      If the size
      of the space requested is zero, the behavior is implementation-
      defined: either a null pointer is returned, or the behavior is
      as if the size were some nonzero value, except that the returned
      ^^^^^
      pointer shall not be used to access an object.

This text guarantees that after:

     char *p = malloc(0);
     char *q = malloc(0);

p == q *only* if both are null pointers (see the underlined "as if"
in the above quoted text), because this guarantee stands for nonzero
values of the argument.  A strictly conforming program can trivially
check if this is the case and expose your hypothetical implementation
as non-conforming.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Fergus Henderson wrote:
> Why would the implementation _care_ when the last free() occurs?

Almost all malloc implementations have storage overhead
associated with each live allocation, and they want to
liberate the overhead storage when they can.  One could
concoct an implementation that had some weird special
handling for 0-sized allocations, but there is no reason
for doing so, and all implementations I know of that
support 0-sized allocations treat it the same way as any
positive-sized request (after adding 1 or not, depending
on the implementation).


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi All,

     As per the standard what is the result of passing NULL to both malloc and free?

Regards,
Mohan.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mohanasundaram wrote:
 > Hi All,
 >
 >      As per the standard what is the result of passing NULL to both malloc and free?
 >

The rules in the C++ standard for malloc and free are the same as in C.

The malloc function takes an integer argument representing size, not NULL, which
is a null pointer constant.

Assuming you meant malloc(0), the results depend on the implementation. An
implementation is allowed always to return a null pointer, or to return a unique
pointer if it can (it's possible to run out of address space). It cannot return
a pointer to an existing object. Whatever the return, you are not allowed to
dereference the pointer, because it need not point to allocated memory. (You
asked for 0 bytes, after all.)

I don't find anything in either standard that disallows always returning the
same non-null address for malloc(0), as long as that address is not othewise used.

The short answer is that malloc(0) is allowed, but you can't depend on doing
much with the result.  Allowing malloc(0) simplifies some algorithms.

Passing a null pointer to free() is allowed, and has no net effect.

The net result of these rules is that you can always call free (once) with the
result you got from malloc.

--
Steve Clamage, stephen.clamage@sun.com


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Mohanasundaram wrote:
 >
 > Hi All,
 >
 >      As per the standard what is the result of passing NULL to both malloc and free?

In C, the behavior of malloc(NULL) depends upon your implementation.
1. NULL can be an integer constant expression with a value of 0, in
which case you've done the eqivalent of calling malloc(0). Per 7.20.3p1
of the C standard:

"If the size of the space requested is zero, the behavior is
implementation defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that the
returned pointer shall not be used to access an object."

2. NULL can be an integer constant expression with a value of 0, cast to
void* (this is not permitted in C++). In that case, malloc(NULL) is
equivalent to malloc((void*)0), which in turn is equivalent to
malloc((size_t)(void*)0). The result of (size_t)(void*)0 is
implementation-defined; it can be any valid size_t value. On a great
many implementations, it will be 0, but there are real implementations
where it might not be, and portable code should not count on that.

free(NULL) is much simpler. Per 7.20.3.2p2 of the C standard: "If ptr is
a null pointer, no action occurs.".

The C++ standard incorporates by reference most of the C standard
library's description. The only changes it makes are to specify that
malloc() does not call ::operator new(), and free() does not call
::operator delete().

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steve Clamage <Stephen.Clamage@Sun.COM> wrote in message news:<c010pa$479$1@news1nwk.SFbay.Sun.COM>...
 >
 > The net result of these rules is that you can always call free (once) with the
 > result you got from malloc.
 >
So I take it MSVC 6's crash on:

char* x = new char[0];
delete [] x;

is most definitely non-compliant...?

Dylan


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In comp.std.c Steve Clamage <Stephen.Clamage@sun.com> wrote:
>
> I don't find anything in either standard that disallows always returning the
> same non-null address for malloc(0), as long as that address is not othewise used.

C99 7.20.3:

        If the size of the space requested is zero, the behavior is
        implementation-defined: either a null pointer is returned, or
        the behavior is as if the size were some nonzero value, except
        that the returned pointer shall not be used to access an object.

C90 contained slightly different language that was more easily misread,
but the intent was the same.

-Larry Jones

It's either spectacular, unbelievable success, or crushing, hopeless
defeat!  There is no middle ground! -- Calvin


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 8 Feb 2004 15:32:59 +0000 (UTC), wizofaus@hotmail.com (Dylan
Nicholson) wrote:

>
>Steve Clamage <Stephen.Clamage@Sun.COM> wrote in message news:<c010pa$479$1@news1nwk.SFbay.Sun.COM>...
> >
> > The net result of these rules is that you can always call free (once) with the
> > result you got from malloc.
> >
>So I take it MSVC 6's crash on:
>
>char* x = new char[0];
>delete [] x;
>
>is most definitely non-compliant...?

Bear in mind the following differences:

A new-expression like
 new T // T is some type
 new T[size}
is a syntactical construct that causes memory to be allocated by the
memory allocation function associated with type T, followed by
contructor invocation(s) for the allocated object(s).

The C++ standard library contiains six different overloads of operator
new, a function that can be called explicitly to allocate raw memory.
You can also write your own overloads, and replace some of the default
versions. The rules are given in the C++ standard section 18.4.1 and
3.7.3. A new-expression invokes some version of operator new, as
explained in section 5.3.4.

C++ also inherits library functions malloc and free from C, which can
be called explicitly to manage raw storage. The C++ standard does not
require that malloc (or free) be used in the implementation of new (or
delete) expressions, or of operator new (or operator delete).

The code you show involves a new-expression and a delete-expression,
not direct calls to malloc or free.

I read section 5.3.4 to say that the expression
 new T[0]
is ill-formed, for any type T. The standard requires a strictly
positive value for the constant-expression giving the array size. But
I tried a couple of compilers at full warning levels, and neither
complained about new char[0].

If the code is invalid, the standard imposes no requirements on the
behavior of the program. But it seems to me that an implemention
allowing the expression should also allow deleteing the pointer that
was returned.

Calling the operator new function explicitly is a different story,
however. The expression
 operator new(0)
is valid. If the operation succeeds, it must return a unique address
for each call, which can be passed to the corresponding operator
delete().


---
Steve Clamage, stephen.clamage@sun.com


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 8 Feb 2004 15:32:59 +0000 (UTC), lawrence.jones@ugsplm.com
wrote:

>
>In comp.std.c Steve Clamage <Stephen.Clamage@sun.com> wrote:
>>
>> I don't find anything in either standard that disallows always returning the
>> same non-null address for malloc(0), as long as that address is not othewise used.
>
>C99 7.20.3:
>
>        If the size of the space requested is zero, the behavior is
>        implementation-defined: either a null pointer is returned, or
>        the behavior is as if the size were some nonzero value, except
>        that the returned pointer shall not be used to access an object.
>
>C90 contained slightly different language that was more easily misread,
>but the intent was the same.
>

Yes, and as I said, I don't see anything that prohibits always
returning the same non-null address.

Suppose the malloc/free implementation reserves one byte, malloc(0)
always returns the address of that byte, and free() of that address is
a no-op. I don't see any rule violation.
---
Steve Clamage, stephen.clamage@sun.com


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

wizofaus@hotmail.com (Dylan Nicholson) writes:
> Steve Clamage <Stephen.Clamage@Sun.COM> wrote in message
> news:<c010pa$479$1@news1nwk.SFbay.Sun.COM>...
>  > The net result of these rules is that you can always call free
>  > (once) with the result you got from malloc.
>  >
> So I take it MSVC 6's crash on:
>
> char* x = new char[0];
> delete [] x;
>
> is most definitely non-compliant...?

I'm posting in comp.std.c.  From that point of view, I'm not sure
whether crashing (at run-time?) on a syntax error is non-compliant.
As long as it generates a diagnostic during compilation, it's probably
all right.

As far as C++ is concerned, I don't know whether the delete []
operator follows the same rules as free().  I've redirected followups
to comp.lang.c++.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stephen Clamage <Stephen.Clamage@Sun.COM> wrote in message news:<r3pc20p2s8em84n26s0aa2jh9gi3eeu1ke@4ax.com>...
 > On Sun, 8 Feb 2004 15:32:59 +0000 (UTC), lawrence.jones@ugsplm.com
 > wrote:
 >
 > >
 > >In comp.std.c Steve Clamage <Stephen.Clamage@sun.com> wrote:
 > >>
 > >> I don't find anything in either standard that disallows always returning the
 > >> same non-null address for malloc(0), as long as that address is not othewise used.
 > >
 > >C99 7.20.3:
 > >
 > >        If the size of the space requested is zero, the behavior is
 > >        implementation-defined: either a null pointer is returned, or
 > >        the behavior is as if the size were some nonzero value, except
 > >        that the returned pointer shall not be used to access an object.
 > >
 > >C90 contained slightly different language that was more easily misread,
 > >but the intent was the same.
 > >
 >
 > Yes, and as I said, I don't see anything that prohibits always
 > returning the same non-null address.
 >
 > Suppose the malloc/free implementation reserves one byte, malloc(0)
 > always returns the address of that byte, and free() of that address is
 > a no-op. I don't see any rule violation.

I read the above section as requiring that if malloc(0) doesn't return
a null pointer, then there be some value of 'n', possibly different
for each call to malloc(0), for which the behavior of malloc(n) would
be identical to the actual behavior of malloc(0). Fow what size n is
the behavior of malloc(n) the same as the behavior you suggest for
malloc(0)?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kuyper <kuyper@saicmodis.com> wrote in message
news:<40240FCD.9A516495@saicmodis.com>...

> 2. NULL can be an integer constant expression with a value of 0, cast
> to void* (this is not permitted in C++). In that case, malloc(NULL) is
> equivalent to malloc((void*)0), which in turn is equivalent to
> malloc((size_t)(void*)0). The result of (size_t)(void*)0 is
> implementation-defined; it can be any valid size_t value. On a great
> many implementations, it will be 0, but there are real implementations
> where it might not be, and portable code should not count on that.

However, the conversion of ((void*)0) to an integral type requires an
explicit cast.  If this is the definition of NULL, then malloc(NULL)
should not compile.

> free(NULL) is much simpler. Per 7.20.3.2p2 of the C standard: "If ptr
> is a null pointer, no action occurs.".

> The C++ standard incorporates by reference most of the C standard
> library's description. The only changes it makes are to specify that
> malloc() does not call ::operator new(), and free() does not call
> ::operator delete().

Yes, but the removal of the liberty to define NULL as ((void*)0) means
that in C++, malloc(NULL) is always legal, where as in C, there are
implementations where it may fail.

--
James Kanze           GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stephen Clamage wrote:
> Yes, and as I said, I don't see anything that prohibits always
> returning the same non-null address.

Since Standard C doesn't include 0-sized objects, if there
is a successful malloc(0) in a conforming implementation,
the associated object will occupy at least one byte,
although a s.c. program isn't allowed to access it.
It would be folly for an implementation to return a pointer
to *the same* 0-sized region for multiple concurrent live
allocations, because those allocations can be free()d and
how then would it know when the last free() occurs (unless
it adds the overhead of a reference count, which would have
no other purpose).


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stephen.Clamage@Sun.COM (Stephen Clamage) wrote (abridged):
 > >        If the size of the space requested is zero, the behavior
 > >        is implementation-defined: either a null pointer is
 > >        returned, or the behavior is as if the size were some
 > >        nonzero value, except that the returned pointer shall not
 > >        be used to access an object.
 > [...]
 > Suppose the malloc/free implementation reserves one byte, malloc(0)
 > always returns the address of that byte, and free() of that address is
 > a no-op. I don't see any rule violation.

That would not be allowed if the size were some nonzero value.

     char *a = malloc( 1 );
     char *b = malloc( 1 );
     assert( a != b || a == NULL );

The assert must succeed. So it must also succeed if we replace the 1's
with 0's.

-- Dave Harris, Nottingham, UK


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In comp.std.c Stephen Clamage <Stephen.Clamage@sun.com> wrote:
>
> Yes, and as I said, I don't see anything that prohibits always
> returning the same non-null address.

It says that malloc(0) behaves like, for example, malloc(1).  Do you
think that malloc(1) is allowed to return the same value all the time?

-Larry Jones

They say winning isn't everything, and I've decided
to take their word for it. -- Calvin


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stephen Clamage <Stephen.Clamage@Sun.COM> wrote in message
news:<r9pc20d151sf9k5u2rl3s06jucmhtqj3oe@4ax.com>...

    [...]
> I read section 5.3.4 to say that the expression
>  new T[0]
> is ill-formed, for any type T. The standard requires a strictly
> positive value for the constant-expression giving the array size.

I'm not sure.  I presume you are referring to    5.3.4/6: "Every
_constant-expression_ in a _direct-new-declarator_ shal be an integral
constant expression evaluating to a strictly positive value."  The
following sentence reads "The _expression_ in a _direct-new-declarator_
shall have integral type with a non-negative value."  The grammar at the
top of    5.3.4 reads:

    [...]
    direct-new-declarator:
        [ expression ]
        direct-new-declarator [ constant-expression ]

Because of the hypen, and because the expression is written in italics,
I would interpret "constant-expression" in the first quote to refer to
the gramatical construct in the second production for
direct-new-declarator, and not to be the equivalent of a simple
"constant expression".  In "new char[0]", the [0] matches the first
production above, and not the second, so the constraints of "expressin"
in    5.3.4/6 apply: it must have a non-negative value (but 0 is OK).

In this case,    5.3.4/7 applies: "When the value of the expression in a
direct-new-declarator is zero, the allocation function is called to
allocate an array with no elements.  The pointer returned by the
new-expression is non-null."

> But I tried a couple of compilers at full warning levels, and neither
> complained about new char[0].

> If the code is invalid, the standard imposes no requirements on the
> behavior of the program. But it seems to me that an implemention
> allowing the expression should also allow deleteing the pointer that
> was returned.

The closest I could find is    5.3.5/2: "[...] In the second alternative
(delete array), the value of the operand of delete shall be the pointer
value which resulted from a previous array new-expression."  I can find
nothing which requires that the number of elements be greater than 0, so
I would assume that the delete is legal.

I might add that, unlike the poster you were responding to, when I
tried:

    char* x = new char[0] ;
    delete [] x ;

with VC++ 6.0, it worked as expected.

--
James Kanze           GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]