Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ll-xn!mit-eddie!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: ungetc
Message-ID: <6592@brl-smoke.ARPA>
Date: Mon, 26-Oct-87 15:56:26 EST
Article-I.D.: brl-smok.6592
Posted: Mon Oct 26 15:56:26 1987
Date-Received: Wed, 28-Oct-87 22:23:11 EST
References: <203@PT.CS.CMU.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <203@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
>  What type of mire might I be falling into if I do this with getc and ungetc?
>    char c;
>    c = getc(ifile);
>    ungetc(c,ifile);
>    BTW  I'm not worried about c = EOF.

The most likely source of trouble would be in feeding a (char)
to ungetc(), which wants an (int).  Promotion of the (char) to
an (int) may produce an unpleasant surprise in some environments,
while in others it would be no problem at all.  There shouldn't
be any concern with the ungotten character, other than to realize
that it changes the apparent (external) behavior of some input
streams such as ttys.  (If you had ungotten a character other
than the last one gotten on the same stream, then interesting
things can occur.)