🚀 go-pugleaf

	my request for an explanation of why anyone (especially pANS)
would give as silly an answer as 0 for malloc(0) generated a few useful
replies (thanks guy, brad, gwyn and kenneth) but a lot of
people were confused by my misstatement at the end. so let me rephrase:

	malloc(n) returning 0 is, to me, an error condition. that is,
i should pack up and go home. (of course i check malloc's return value).
But now, thanks to pANS, i first have to check if n==0. this is a pain
in the butt.

	the ONLY justification put forward is some stuff about zero-sized
objects (gwyn admits to being the point of contact). the only
point actually mentioned is devising semantics for zero-sized objects;
hascall derisively says ``And what would you have malloc(0) return?
An Address?''. paraphrasing kenneth's reply, ``gosh, yes, i would return an
address!''.
	lets get this straight; malloc has never said (at least until VERY recently)
that it returns a pointer to n bytes of storage. it has always said at least
n bytes of storage and the reason is clear if you look how most malloc's
are implemented; they almost always allocate an integral number of
machine words, rounding the actual request up. given that, what is
all the whining about? can't malloc(0) return a pointer to 1 (or 2 or 4)
bytes? of course, everyone would be happy now, wouldn't they?
and, innovative as it may be, 0 could revert to meaning 'I ran out of storage'
and we could even get rid of the peculiar special cases of giving
zero pointers to realloc. call me old-fashioned but 0 means
no pointer, end of list, you can stop here. don't let it become a
legitimate return value; just say no.

(and if anyone accuses me of flaming, let me say i didn't
actually say the decision was batshit).