🚀 go-pugleaf

> When I try to make libtest.a in libg++-1.35.0/tests I get the following
> error. Can anyone help please?
> int.XPSet.h:53: parse error at null character

You don't say what sort of machine this is, but it sounds like the bug
in system V that I reported last month in the enclosed article.

| Subject: can't use system V's setvbuf()
| Message-ID: <4314@orca.WV.TEK.COM>
| Date: 23 Aug 89 21:22:05 GMT
| 
| 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.

Here's my setvbuf hack, from cplus-lex.c.  It happens to do the right
thing with my version of system V, which is derived from release 3.2.
It "knows" about internal stdio details that it has no business
knowing, and it could very well fail under a different Unix.

/*
 * The stdio routine setvbuf() cannot be trusted to use the buffer passed
 * to it.  If the size of the buffer is less than 8 bytes, it will ignore it
 * and malloc a new one, because Unix system V release 3.2 stdio requires an
 * 8-byte slop, for reasons relating to resynchronization after a signal.
 * Since this compiler does not try to recover from signals, it should be
 * all right to override this hack.  However, it is only an educated guess
 * that the hack is unneeded.  -=- andrew@frip.wv.tek.com
 */
int setvbuf(stream, buf, type, size)
FILE *stream;
char *buf;
int type, size;
{
	if (type != _IOFBF) {
		abort();
	}
	stream->_flag = stream->_flag & ~(_IOMYBUF|_IONBF|_IOLBF) | _IOFBF;
	if (buf == NULL) {
		abort();
	}
	stream->_base = (unsigned char *) buf;
	_bufend(stream) = stream->_base + size;
	stream->_ptr = stream->_base;
	stream->_cnt = 0;
	return 0;
}

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