Xref: utzoo comp.std.c:991 comp.lang.c:17358
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!dlb!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: realloc
Message-ID: <3240@goofy.megatest.UUCP>
Date: 1 Apr 89 07:01:29 GMT
References: <9962@smoke.BRL.MIL>
Organization: Megatest Corporation, San Jose, Ca
Lines: 71

From article <9962@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ):
> In article <3229@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>>Can anyone suggest a legitimate reason why they would want to do such
>>a thing?
> 
> I already did that.


Well excuuuusee ME!

The posting which I assume you refer to arived days after I posted
the above question.  In fact, somehow it got here *after* the 
"I already did that" posting (but in the same batch).

Might I suggest to everyone:

  1) if you are quoting are article, please include enough context 
  so that the reader can figure out what the quote
  is about -- (btw, I quoted the *entire* response above!) -- and

  2) if you refer to another article, or to a manual, or
  to a book or whatever, please identify it as best you can.

Thenkyewverymuch.

Now then.

This discussion is about the proposed ANSI behavior of malloc(0): namely
returning (char*)0.

I just now read the article alluded to above.

No sale.

Unless there are existing systems that behave in the proposed way -- 
(are there?) -- the new spec just breaks programs for no reason,
and perhaps too quietly.

I mean, if you really want a standard procedure that returns
(char*)0 when told to return a pointer to zero bytes, just define a
new one for Pete's sake!  Call it zzalloc, or something.

Looks to me like the only reasonable choices are

	1. Document the behavior as unpredictable; and
  
	2. Have malloc(0) return a pointer distinct from 0 and from all
	   other mallocked pointers, or else return 0 and set errno
	   if there is not enough memory available for the heap-overhead
	   of an empty packet. ("The set containing only the empty set 
	   is not empty," a famous Math professor used to be fond
           of reminding people.)


Given an xor, I prefer number 1, but I really would like to have
both!  That way, old programs will probably work, but I'll be warned
to check them over, and that they may not be portable.

Why is 1 better than the proposal?  Because otherwise somebody reading
the standard might be lulled into thinking that he is writing a portable
program when he's not. It is the ANSI-STANDARD, after all (ta-ta!).

Sidebar:

  I recall once, many many moons ago, writing a LISP-system in C.
  I was "young and easy, about the lilting house and happy as the grass
  was green", one might say, and I thought it was cool to allocate
  pointers to no bytes to represent t and nil. Made checking an S-
  expression for t-ness and nil-ness real quick...  and why allocate
  bytes when you're not going to use them, eh?  Okay, now maybe I know
  better,  but so what?