More bizarre bourne shell
hardy at sdccsu3.UUCP
hardy at sdccsu3.UUCP
Wed May 16 00:03:44 AEST 1984
I apologize for not completely specifying my source. Since I don't have
all versions of the Unix User's Manual, I will quote directly from the
Unix System User's Manual, System V, 1983, brk(2), page 1, paragraph 1:
"The newly allocated space is set to zero."
No mention is made about partial pages or sbrk being lazy. Indeed, I
would expect from the above statement that the sequence:
p = sbrk(2); *p = 1; sbrk(-2); p = sbrk(2);
should result in *p being zero. On all versions of Unix I know about,
including System V, it is zero only if p happens to point to a new page.
The real problem is that it was not documented what sbrk did prior to
System V, but that "everybody knows" that sbrk zeros memory. Obviously,
the poor shmuck System V technical writer "knew" that. What most people
don't know, or realize, or intuit from the documentation, is that sbrk is lazy.
They would only learn this the hard way if they did a reallocation sequence
as above or scribble above the break as the Bourne Shell does.
Personally, I would prefer sbrk not being lazy. I would like to see anyone
document sbrk in 25 words or less so that the above reallocation sequence
can be explained and give predictable results on all incantations of Unix.
The Bourne Shell does not depend on sbrk zeroing memory, but sbrk being lazy.
This is not a hardware dependency, since all versions of Unix I know about
on all machines I know about work the same way.
The point is that this "undocumented feature" of sbrk has propogated
throughout all versions of Unix, that at least one critical program,
the Bourne Shell, depends upon it, and that the latest and greatest
documentation straight from AT&T contradicts this usage.
All of this may sound like "griping". It is. After spending many days
discovering these little oddities of the Bourne Shell, I felt compelled
to share the experience. After all, I am from California...
Michael Christensen
Unix System V Project Manager
Alcyon Corporation
More information about the Comp.unix.wizards
mailing list