[net.unix-wizards] rcs problem

msc@qubix.UUCP (Mark Callow) (04/07/84)

The rcs distributed with 4.2 contains the following code fragment
(in src/rdiff/diff.c):

	static	char sccsid[] = "@(#)diff.c 4.1 10/9/80";

	extern	char _sobuf[];

	main(argc, argv)
		int argc;
		char **argv;
	{
		.
		.
		setbuf(stdout, _sobuf);
		.
	}

_sobuf is a buffer declared deep within the stdio library.  Needless
to say this undocumented buffer does not appear in all stdio libraries
as I discovered while porting rcs to Sun Unix 4.2BSD.
(It worked in Sun 4.1c).

Does anyone know what this setbuf is for?  I've just removed it for now.
Walter Tichy are you out there?
-- 
From the Tardis of Mark Callow
msc@qubix.UUCP,  decwrl!qubix!msc@Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc

"I'm a citizen of the Universe, and a gentleman to boot."

dmmartindale@watcgl.UUCP (Dave Martindale) (04/07/84)

In versions of stdio which use _sobuf, it is the already-allocated internal
buffer used for the standard output stream.  "setbuf(stdout, _sobuf)"
forces stdio to buffer stdout even when it would ordinarily not do so
(e.g. output is to a tty) but cleverly uses the buffer which is already
allocated to that purpose rather than allocating a new one.
As you discovered, rather non-portable.

chris@umcp-cs.UUCP (04/10/84)

"_sobuf" and "_sibuf" are (the) two pre-allocated buffer areas that
the Berkeley stdio routines attach to stdin and stdout.  In order
to guarantee full (rather than line) buffering, the code

	extern char _sobuf[];
	setbuf (stout, _sobuf);

does the trick.  Of course it's not portable; nobody said stdio has
to have preallocated buffers named "_sobuf" and "_sibuf".

I'm really not sure why they did that, rather than just malloc()ing
the buffers the way the _iob[3] to _iob[NOFILE-1] are done ...
performance maybe.

[While I'm thinking of it:  Why, oh why, didn't they make "setbuf"
able to set line buffering???]
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris.umcp-cs@CSNet-Relay