Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!cornell!rochester!ur-tut!sunybcs!boulder!hao!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: ungetc and scanf (was: (So-Called) ANSI C)
Message-ID: <7008@brl-smoke.ARPA>
Date: 9 Jan 88 09:20:51 GMT
References: <4668@pyr.gatech.EDU> <2046@haddock.ISC.COM> <400@uniq.UUCP> <6942@brl-smoke.ARPA> <38060@sun.uucp> <6978@brl-smoke.ARPA> <2193@haddock.ISC.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <2193@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>Is strdup() part of the ANSI library now?  It wasn't in the Oct86 Draft.

No, but it's in the SVID.  It's such a small function that the ANSI C
implementation can easily have its own version, with a reserved name or
simply as a static function in the scanf.c source file.

>If I'm not mistaken, the character which sscanf() pushes back via ungetc() is
>always the same as the last character read via getc().  Hence the buffer need
>not be modified.  It would suffice to replace the ungetc() call with the
>equivalent of "--fp->_ptr".

That's a better approach, but you have to also deal with unbuffered I/O.

>Btw, the Oct86 Draft says that "one character of pushback is guaranteed".
>It's unclear to me whether this requires an ungetc() to succeed immediately
>after a scanf().

Yes, it does.  It is not stated that scanf() uses ungetc() and in fact
many people think that it shouldn't.