Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!zephyr.ens.tek.com!orca!rushmore!andrew
From: andrew@rushmore.WV.TEK.COM (Andrew Klossner;685-2505;61-201;;frip)
Newsgroups: gnu.g++.bug
Subject: can't use system V's setvbuf()
Message-ID: <4314@orca.WV.TEK.COM>
Date: 23 Aug 89 21:22:05 GMT
Sender: nobody@orca.WV.TEK.COM
Lines: 20

Under system V, cplus-lex.c has a cute hack that uses setvbuf to trick
stdio into treating a chunk of memory as a file, so that the lexer can
read characters from a stored inline function.  But the hack is fragile
and breaks easily.  A problem that I have encountered (while trying to
make the libg++ tests) is that, if the buffer given to setvbuf is
shorter than eight bytes long, setvbuf will (in violation of its man
page) ignore the buffer and call malloc to get a bigger one.  The
comment in setvbuf, in vanilla system V release 3.2, says that stdio
needs at least eight bytes of slop because of synchronization problems
after signals.

I hacked the hack with a local copy of setvbuf that operates more
faithfully.  But I think the "right" thing to do here is to lose the
hack, and move the switch between file input and inline-buffer input up
above the stdio abstraction.  Mucking with the internals of a stdio
(*FILE) is impolite, and ironic when done in the name of a language
that champions strong data abstraction.

  -=- Andrew Klossner   (uunet!tektronix!frip.WV.TEK!andrew)    [UUCP]
                        (andrew%frip.wv.tek.com@relay.cs.net)   [ARPA]