Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <2083@ttrdc.UUCP>
Date: 10 Jan 88 19:07:08 GMT
References: <4668@pyr.gatech.EDU> <2046@haddock.ISC.COM> <400@uniq.UUCP> <6978@brl-smoke.ARPA>
Organization: AT&T, Skokie, IL
Lines: 27

In article <6978@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <38060@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
> >The trouble is that "_doscan" uses "ungetc" ...
> 
> Ah, now I see the problem.  It is the caller's buffer, not stdio's,
> that is being modified.  That is clearly a bug, which is relatively
> easy to fix in sscanf() by strdup()ing the caller's buffer.
> 
> This further reinforces the position that ANSI C *scanf() should not
> use ungetc(), although I think the AT&T folks believe that by allowing
> a couple of extra "slop space" bytes in a FILE structure's buffer they
> can get away with using ungetc().  I've never been convinced of that.

Pray tell, what kind of implementation would you suggest for scan functions
that read from stdio streams, like scanf and fscanf?  For certain types of
objects, these functions do not know when they have finished scanning them
until they have read one character too many.  It may be a bug to try to
actually write this character back when dealing with a fixed buffer (sscanf)
so the implementation should be different here, but it's imperative to do it
with stdio.  Anyhow, I thought that ungetc() was always guaranteed to be able
to stuff back one character when dealing with stdio.  When did that become no
longer true?
-- 
|------------Dan Levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an Engihacker @        |  	<most AT&T machines>}!ttrdc!ttrda!levy
| AT&T Computer Systems Division |  Disclaimer?  Huh?  What disclaimer???
|--------Skokie, Illinois--------|