use of _s[io]buf in stdio library

[John P. Linderman]

> Historically, _sibuf was attached to stdin and _sobuf to stdout,
> voiding the need for malloc() (which could fail, giving one unbuffered
> I/O, which isn't a great excuse for them anyway).
> 
> Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)

malloc() can do worse than fail -- it can succeed.  Consider
everyone's favorite utility, /bin/sort.  During the sort phase,
sort wants a lot of main memory, but, being a good citizen of
unpaged UN*X systems, it would like to return most of it during
the merge phase.  So sort does an sbrk(), and starts reading
lines.  If this triggers a call to malloc() to get a stdio buffer,
the space will be acquired following sort's memory area.  When
the sort phase completes and sort does another brk() to return
its work area, it inadvertantly returns the space that malloc()
got for the stdio buffers.  A core dump will follow shortly
thereafter.

Yes, the ``correct'' thing for sort to do is to use setbuf()
to prevent the call to malloc().  [And, yes, it should really
call setbuffer() under 4.2 and setvbuf() under SysV.]  The
point is, the disastrous interaction of getchar() and brk()
is far from obvious, and it demonstrates the difficulty of
writing a non-trivial library package [like stdio] without
undesirable side-effects.  It also shows why a portable
program may have to acknowledge these side-effects and end
up perpetuating the differences between systems instead of
hiding them.

John P. Linderman  Hopeless Cause Department  allegra!jpl