Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!scgvaxd!wlbr!voder!nsc!hplabs!hp-pcd!hpfclq!kah
From: kah@hpfclq.UUCP (kah)
Newsgroups: net.bugs.usg
Subject: Re: Orphaned Response
Message-ID: <80800001@hpfclq.UUCP>
Date: Wed, 14-Nov-84 23:07:00 EST
Article-I.D.: hpfclq.80800001
Posted: Wed Nov 14 23:07:00 1984
Date-Received: Wed, 14-Nov-84 04:23:28 EST
References: <-61700@clyde.UUCP>
Organization: Hewlett-Packard - Fort Collins, CO
Lines: 32
Nf-ID: #R:clyde:-61700:hpfclq:80800001:37777777600:1136
Nf-From: hpfclq!kah    Nov  6 14:07:00 1984

/***** hpfclq:net.bugs.usg / clyde! /  6:59 pm  Oct 15, 1984*/
In the USG (AT&T) Unix System V Release 2 Programmer Reference Manual
lists the calling sequence for setvbuf(3S) [under setbuf(3S)] as:

int setvbuf (stream, buf, type, size)

the actual code, however, is looking for:

int setvbuf (stream, type, buf, size)

This problem will be reported to the Unix Hotline shortly.  ...
/* ---------- */

The mixup in parameter order is the least of the problems with the V.2
setvbuf source.  The source contains numerous bugs including:
	(1) They never set iop->_base = buf;
	    I.e., the parameter "buf" is never even used!
	(2) If the user does not provide a buffer, the code uses malloc
	    to generate one.  But it doesn't set the _IOMYBUF bit so
	    that the buffer space can be freed later when the file is
	    closed.
	(3) The tests to determine when a malloc should be done are 
	    wrong .
	  ...

In short the "setvbuf.c" source file is a "basket case"; if you need 
the functionality of setvbuf, I suggest you write your own.  That's
what we did.

Kathy Harris
Hewlett Packard, Fort Collins Systems Division
hpfcla!kah