Bizzare Bourne Shell

[chris at umcp-cs.UUCP]

Now hold on a minute here ...

	From: hardy at sdccsu3.UUCP

	Unix Guru Question:  what is the value of *p after the
	second sbrk?

		p = sbrk(0); *p = 1; sbrk(2);

Undefined.  sbrk(0) simply returns the address of the current break.
If there is room beyond the current break, then *p will be one.  If
not, then you get that memory fault you're griping about, and I don't
really want to know the details....

	The Unix Programmer's Manual says that all newly allocated
	memory is initialized to zero.  However, on Unix Version
	6, 7, System III and System V, *p is one!  Indeed, Unix
	only zeros memory when a new MMU segment of memory is
	allocated.

Where does it say that?  Not in ``man 2 brk'' (where one finds the
sbrk manual).  If you have a partial page, obviously sbrk is going
to be lazy.  Use calloc() if you want zeroed memory.  (I know, your
complaint is that the Bourne shell doesn't - so that makes the
Bourne shell guilty of making hardware assumptions.  But don't
blame the manuals.)

	Also, this code will generate a memory fault if p happens
	to point to a new MMU segment.  I contend that this really
	is a Unix bug, not a "feature".  Either sbrk should not
	initialize any memory, or it should always initialize
	memory.  The half-assed attempt it does now can only lead
	to bizzare usages of this "feature".

It should be obvious that memory has to be initialized to *something*,
or you'll have a huge security hole.  But why initialize it more than
once?  That's what calloc() is for.

	I really question whether a program as critical as the
	Bourne Shell should depend upon not merely an undocumented
	"feature", but one seemingly CONTRADICTED by the documentation.

The Bourne shell should *not* depend on it.  (And I can't stand the fake
ALGOL either.)

(Anybody know if ksh has this kind of code in it? :-) )
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland