🚀 go-pugleaf

In article <3229@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes:
> Gack.
> 
> The realloc((char*)0, size) thing was bad enough. What's this all
> about? [realloc(ptr, (size_t)0) === free(ptr)]
> 
> Stuff like this just makes it hard to port ANSII programs to
> old systems. Also makes it harder to convert an old system to ANSII.
> I can't think of any good reason to add such a silly spec. What am I
> missing?
> 
> Can anyone suggest a legitimate reason why they would want to do such
> a thing?

The idea is to avoid applications having to special case zero.
Thus, it should be possible to malloc for a size of zero, realloc
to or from a size of zero, and free something with a size of
zero.  Since C does not allow one to declare zero-size objects,
there was some objection to requiring implementations to allow
for dynamically created zero-size objects -- thus the compromise
of allowing pointers to zero-size objects to either be unique
pointers like all other object pointers, or all NULL at the
implementation's discretion.

Ease of porting to non-complying systems is NOT one of the goals
of the standard; ease of porting to COMPLYING systems IS.  Most
existing implementations I know of already meet this spec -- they
either return unique pointers for zero-size objects or consider
it an error and return NULL.  Since existing systems work both
ways, portable programs can't depend on a specific behavior and
so will work just fine with an ANSI implementation.

----
Larry Jones                         UUCP: uunet!sdrc!scjones
SDRC                                      scjones@sdrc.UU.NET
2000 Eastman Dr.                    BIX:  ltl
Milford, OH  45150                  AT&T: (513) 576-2070
"When all else fails, read the directions."