Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <38060@sun.uucp>
Date: 6 Jan 88 21:00:59 GMT
References: <4668@pyr.gatech.EDU> <2046@haddock.ISC.COM> <400@uniq.UUCP> <6942@brl-smoke.ARPA>
Sender: news@sun.uucp
Lines: 20

> > *	I believe this to be a legitimate bug in sscanf that will
> > *	eventually need to be fixed anyway to achieve ANSI compatibility.
> 
> Yup, it must be a bug.  It doesn't appear to exist in the portable
> C implementation of _doscan() shipped with SVR2.0.

It ultimately exists in "ungetc", not "_doscan".  The trouble is that "_doscan"
uses "ungetc" (the SVR2.0 version does, the 4.3BSD version does, and the SunOS
3.2 version, which is basically the SVR2.0 version with most, but not all, of
the "ungetc"s eliminated to give it performance comparable with the 4.3BSD
version, does), that "ungetc" works by writing to the buffer for the standard
I/O stream, and "sscanf" works by using the string fed to "sscanf" as the
buffer.

Did you try it on a machine with a compiler that supports putting strings into
text space (e.g., the 4.3BSD compiler with the "-R" option)?  I would be very
surprised if it *did* work under those circumstances.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com