Memory question

[John Potter]

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

 

[James Kuyper]

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)?

 

[Dave Harris]

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

 

[James Kuyper]

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.

 

[Steve Clamage]

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.

 

[Fergus Henderson]

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?

 

[James Kuyper]

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.

 

[Wojtek Lerch]

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.

 

[Dan Pop]

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

 

[lawrence.jones]

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

 

[Douglas A. Gwyn]

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

 

[Rolf Magnus]

In C, perhaps, not in C++.

Unless you have a _very_ old, non-conforming compiler.

It would be nice if C++ not only allowed that (which it doesn't) but
required it, so that certain errors could be detected, but alas...

Actually, it would be better if NULL wasn't defined at all in C++.

 

[Alf P. Steinbach]

Actually, it would be better if NULL wasn't defined at all in C++.

And how did you come to that conclusion?

 

[Ron Natalie]

And how did you come to that conclusion?

Actually it would be better if NULL was some magic cookie that
wasn't a integer zero constant expression. The feature is one of those
cutesy holdovers form the archaic days in C that we could have done
without.