what malloc(0) should returns?

[Keith Thompson]

As with many C oddities, it was more an issue of documenting what
existing pre-ANSI C implementations did, not specifying ideal behavior.

A lot of things in C would be very different if it had been specified
fully before implementations were written -- but it never would have
caught on.

Agreed. I think the gist of the description is that malloc(0) isn't
allowed to blow up; the standard goes into some (possibly unnecessary)
detail about *how* it's not allowed to blow up.

But it seems to me the C89 standard *could* have nailed this down more
tightly than it did. It also mandated that free(NULL) does nothing;
in some existing implementations at the time, it would crash.
Mandating that malloc(0) returns a unique non-null pointer (unless
memory has run out) would have been just as easy; implementations
would just have had to change to meet the new requirement.

It's too late now, I suppose.

 

[Keith Thompson]

Does this imply that if an implementation makes malloc(0) return a
non-null pointer, this pointer shall be free()d?

What do you mean by "shall"?

There's no requirement to free() any malloc()ed pointer; terminating a
program without free()ing anything is perfectly acceptable as far as
the standard is concerned.

It's true that the result returned by malloc(0) *may* be passed to
free().

 

[jaysome]

depends if you call access violations graceful

To me, "graceful" in Windows means no BSOD, just like "graceful" in
*NIX means no kernel panic :^)

Best regards

 

[Chris Dollin]

You snipped one that I showed earlier.

Hell's teeth, man, cut me some slack -- it's nearly Christmas. I
/did not see/ an anomaly. Write the thing in a reply and explain
what the problem is. It's probably too obvious for me to be able
to see it without help.

 

[Chris Dollin]

Since malloc() is a reserved function name, let me illustrate with
a different function-name. This also lets me use malloc() for the
"hard parts".
(fx:snip)

Given the obvious preconditions, the behavior of this code is
well-defined (which may suffice to label it "sensible"), but would
it suffice to replicate the Standard's requirements for malloc()?

No, because the Standard says otherwise -- but CB seemed to be
arguing that even without that explicit requirement the unique
magic pointer approach couldn't be made consistent.

 

[CBFalconer]

Hell's teeth, man, cut me some slack -- it's nearly Christmas. I
/did not see/ an anomaly. Write the thing in a reply and explain
what the problem is. It's probably too obvious for me to be able
to see it without help.

</requoted>

The anomaly appears if the results of the malloc calls are non-NULL
and not distinct, i.e. non-compliant.

 

[Random832]

Or it might NOT be unchanged, since we've established that in the
implementation method being discussed, malloc(0) is a special case and
not a normal heap pointer.

 

[WaterWalk]

What do you mean by "shall"?

There's no requirement to free() any malloc()ed pointer; terminating a
program without free()ing anything is perfectly acceptable as far as
the standard is concerned.

It's true that the result returned by malloc(0) *may* be passed to
free().

Oh, what I mean is: if a lot of malloc(0) is called and the returned
results are not free()d, then this is still memory leak. Am I right?

 

[Guest]

Oh, what I mean is: if a lot of malloc(0) is called and the returned
results are not free()d, then this is still memory leak. Am I right?

Yes, if you do not free a non-NULL result from malloc, even with a size
of zero, you have a memory leak.

 

[CBFalconer]

Yes, if you do not free a non-NULL result from malloc, even with
a size of zero, you have a memory leak.

If you stop to think about it the system has to keep track of
allocations somewhere, even in the case of a zero size returning
non-NULL, and the only way to signal the release of that
information is via free.

 

[Joe Wright]

If you stop to think about it the system has to keep track of
allocations somewhere, even in the case of a zero size returning
non-NULL, and the only way to signal the release of that
information is via free.

Hi Chuck. Merry Christmas.

If I were King, the argument to malloc would be defined > 0. An argument
0 would force a malloc failure and a NULL return. free(NULL) is harmless
and so, voila, no problem.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...

If I were King, the argument to malloc would be defined > 0.
An argument 0 would force a malloc failure and a NULL return.
free(NULL) is harmless and so, voila, no problem.

Bad idea. The system may be used to process variable length data,
which may be empty. This size can be coming in as a parameter to
some routine or other. You don't want to have to test all sorts of
special cases in that routine. Although with the existing C
standard you probably have to:

if (!sz) sz++;
if (!(p = malloc(sz)) failure();
else carryon();

which is why I consider systems that return distinct pointers for
malloc(0) superior. They will forgive forgetting to make the
preliminary check.

 

[Keith Thompson]

Bad idea. The system may be used to process variable length data,
which may be empty. This size can be coming in as a parameter to
some routine or other. You don't want to have to test all sorts of
special cases in that routine. Although with the existing C
standard you probably have to:

if (!sz) sz++;
if (!(p = malloc(sz)) failure();
else carryon();

which is why I consider systems that return distinct pointers for
malloc(0) superior. They will forgive forgetting to make the
preliminary check.

In other words, they will fail to diagnose the failure to make the
required check. How friendly.

If I were King, the behavior of malloc(0) would be well-defined. I
might flip a coin to decide *how* it's defined. Heads (i.e., my
portrait) means it's equivalent to malloc(1), except that the pointer
may not be dereferenced; tails means malloc(0) returns a null pointer.
The coin toss would occur only once, and would determine the rule to
be written in the standard. Sufficient bribery might induce me to use
a weighted coin.

 

[P.J. Plauger]

In other words, they will fail to diagnose the failure to make the
required check. How friendly.

If I were King, the behavior of malloc(0) would be well-defined. I
might flip a coin to decide *how* it's defined. Heads (i.e., my
portrait) means it's equivalent to malloc(1), except that the pointer
may not be dereferenced; tails means malloc(0) returns a null pointer.
The coin toss would occur only once, and would determine the rule to
be written in the standard. Sufficient bribery might induce me to use
a weighted coin.

But what happened instead was much worse. I fought for several meetings
to have malloc(0) return a unique non-null pointer -- just as the Unix
implementation had been doing since day one, not to mention ours (then
Whitesmiths) and all others I knew about. As CBFalconer observed, a
zero-size dynamic array is a naturally occuring thing, just like while
loops that loop zero times. But for some reason Larry Rosler argued
vehemently for malloc(0) being an error, even though this was not in
the best interests of Bell Labs, his employer. By the time I'd convinced
Rosler of my view, most of the committee had grown tired of the whole
debate. So they settled on the worst possible "compromise" -- neither
behavior is guaranteed.

A coin toss would have been a better resolution.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[CBFalconer]

.... snip ...

But what happened instead was much worse. I fought for several meetings
to have malloc(0) return a unique non-null pointer -- just as the Unix
implementation had been doing since day one, not to mention ours (then
Whitesmiths) and all others I knew about. As CBFalconer observed, a
zero-size dynamic array is a naturally occuring thing, just like while
loops that loop zero times. But for some reason Larry Rosler argued
vehemently for malloc(0) being an error, even though this was not in
the best interests of Bell Labs, his employer. By the time I'd convinced
Rosler of my view, most of the committee had grown tired of the whole
debate. So they settled on the worst possible "compromise" -- neither
behavior is guaranteed.

A coin toss would have been a better resolution.

Well, at least now we can point disdainfully at the actual cause of
the problem We can name it the Rosler curse.

BTW, to answer Keiths objection, my nmalloc for DJGPP includes a
provision (non-standard) for injecting run-time hooks, which can
change that behaviour.

 

[Richard Tobin]

So they settled on the worst possible "compromise" -- neither
behavior is guaranteed.

I agree distinct pointers would be better, but the current behaviour
does at least cover the common case: you can malloc an array without
regard for it being possibly empty, and realloc it safely, getting a
real unique value once you need some real memory.

-- Richard

 

[P.J. Plauger]

I agree distinct pointers would be better, but the current behaviour
does at least cover the common case: you can malloc an array without
regard for it being possibly empty, and realloc it safely, getting a
real unique value once you need some real memory.

Uh, no. One of the arguments in favor of permitting malloc(0) to be
erroneous was to let some systems diagnose, even trap out, on such
a call. So it's never portably safe to call malloc(0), and it's never
a sure thing that it'll be treated as an error. Everybody loses.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Richard Tobin]

I agree distinct pointers would be better, but the current behaviour
does at least cover the common case: you can malloc an array without
regard for it being possibly empty, and realloc it safely, getting a
real unique value once you need some real memory.

[/QUOTE]

Uh, no. One of the arguments in favor of permitting malloc(0) to be
erroneous was to let some systems diagnose, even trap out, on such
a call. So it's never portably safe to call malloc(0), and it's never
a sure thing that it'll be treated as an error. Everybody loses.

I think you're misremembering. The standard requires malloc(0) to
return either a distinct pointer or NULL. It's not allowed to treat
it as an error.

-- Richard

 

[P.J. Plauger]

Uh, no. One of the arguments in favor of permitting malloc(0) to be
erroneous was to let some systems diagnose, even trap out, on such
a call. So it's never portably safe to call malloc(0), and it's never
a sure thing that it'll be treated as an error. Everybody loses.

I think you're misremembering. The standard requires malloc(0) to
return either a distinct pointer or NULL. It's not allowed to treat
it as an error.[/QUOTE]

So it seems. The C Standard didn't always end up saying exactly
what the committee decided by consensus.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[av]

In other words, they will fail to diagnose the failure to make the
required check. How friendly.

If I were King, the behavior of malloc(0) would be well-defined. I
might flip a coin to decide *how* it's defined. Heads (i.e., my
portrait) means it's equivalent to malloc(1), except that the pointer
may not be dereferenced; tails means malloc(0) returns a null pointer.
The coin toss would occur only once, and would determine the rule to
be written in the standard. Sufficient bribery might induce me to use
a weighted coin.

why standard says should be: malloc(0)==0 or malloc(0) has to point
some data whose access is illegal

why malloc(0)!=0 has to point to some data
(i.e. "(char*)malloc(0)"
has some memory, but access to it is illegal)?

in how i see
malloc(0) has to return "p" pointer
|header|
^
p
where *(char*)p has to segfault and p should not have memory reserved
for programme