gostas@kuling.UUCP (G|sta Simil{/ml) (08/01/85)
Has anyone got a idea why the stdio-package declares but never
uses two buffers, "_sibuf" and "_sobuf"?
They are declared as s[io]buf[BUFSIZ] in s[io]buf.c (4.2 bsd).
I have thought about using them in my own programs, maybe that's
even what they are for!?
Just grepped through some of the source. Some programs use setbuf()
to make use of _sobuf. Strange was however that most of this programs
seems to be programs who looks into kernel memory, ps, sps, w, who etc.
G|sta Simil{ gostas@kuling.UUCPchris@umcp-cs.UUCP (Chris Torek) (08/03/85)
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). With the advent of variable sized buffers, these should have gone away in 4.2BSD. They are indeed gone in 4.3BSD (and in Sun 1.3). (The 4.3 C library still has the buffers, but they won't get linked in unless you reference them yourself; this was kinder than Sun, where they are completely gone....) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
henry@utzoo.UUCP (Henry Spencer) (08/14/85)
> I have thought about using them in my own programs, maybe that's > even what they are for!? Don't!! They are a detail of the implementation of stdio, and are *not* guaranteed to be present in all implementations. The intent was to make sure that buffers for stdin and stdout were always available if they were needed, whence the names. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
chris@umcp-cs.UUCP (Chris Torek) (08/15/85)
>> I have thought about using them in my own programs... >Don't!! They are a detail of the implementation of stdio, and are *not* >guaranteed to be present in all implementations. In fact, they are *gone* in Sun Unix (1.3? something like that). Quite a surprise, actually. They're also no longer used in 4.3BSD (I think) but are still in the C library (so those of you who have [mis]used them won't notice). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
jpl@allegra.UUCP (John P. Linderman) (08/28/85)
> 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