ungetc

[av]

Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?

[Nils O. Selåsdal]

av wrote:

Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?

ungetc pushes characters back onto the stream, EOF isn't a character.
We already have fclose for closing a stream.

[Joe Wright]

av wrote:

Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?

EOF is not a character in any stream. Trying to 'push' it back onto the
stream doesn't make sense.

Given..
int ch;
ch = getc(pfile);
if (ch == EOF)
{
/* Assuming no error, getting here means the the previous call to
getc(pfile) was the last character in the stream.
*/
}
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[P.J. Plauger]

"Joe Wright" <jo********@com cast.netwrote in message
news:q-*************** *************** @comcast.com...

av wrote:

>Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?

EOF is not a character in any stream. Trying to 'push' it back onto the
stream doesn't make sense.

Given..
int ch;
ch = getc(pfile);
if (ch == EOF)
{
/* Assuming no error, getting here means the the previous call to
getc(pfile) was the last character in the stream.
*/
}

Well, it makes a little bit of sense. The C Standard requires that
ungetc accept EOF as a first argument (and return the failure code
EOF). That supports a "peek" idiom where you loop over a file first
peeking at a character (get/unget) then deciding whether to consume
it.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[av]

On 15 Jul 2006 16:21:46 +0200, "Nils O. Selåsdal" wrote:

>av wrote:

>Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?

ungetc pushes characters back onto the stream, EOF isn't a character.
We already have fclose for closing a stream.

close in the way "pfile->flag|= _EOF;"

[av]

On Sun, 16 Jul 2006 06:26:10 +0200, av <[e-mail] e:

>On 15 Jul 2006 16:21:46 +0200, "Nils O. Selåsdal" wrote:

>>av wrote:

>>Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?

ungetc pushes characters back onto the stream, EOF isn't a character.
We already have fclose for closing a stream.

close in the way "pfile->flag|= _EOF;"

the above seems wrong
noone of you know if it is right "ungetc(EOF , pfile);"?
and for what it is intended to do? :)

[P.J. Plauger]

"av" <[e-mail] e in message
news:4h******** *************** *********@4ax.c om...

On Sun, 16 Jul 2006 06:26:10 +0200, av <[e-mail] e:

>>On 15 Jul 2006 16:21:46 +0200, "Nils O. Selåsdal" wrote:

>>>av wrote:
Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?

ungetc pushes characters back onto the stream, EOF isn't a character.
We already have fclose for closing a stream.

close in the way "pfile->flag|= _EOF;"

the above seems wrong
noone of you know if it is right "ungetc(EOF , pfile);"?
and for what it is intended to do? :)

Two days ago I said:

Well, it makes a little bit of sense. The C Standard requires that
ungetc accept EOF as a first argument (and return the failure code
EOF). That supports a "peek" idiom where you loop over a file first
peeking at a character (get/unget) then deciding whether to consume
it.

Ergo, it is "right" to call ungetc with an EOF first argument
because the C Standard says what happens. It is useful to do so
in a loop where you get a character, immediately unget it, and
only then test to see if you got a character, as in:

while (ungetc(ch = fgetc(pfile), pfile) != EOF)
<do something with ch and maybe consume it>

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[av]

On Sat, 15 Jul 2006 10:57:25 -0400, Joe Wright
<jo********@com cast.netwrote:

>av wrote:

>Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?

EOF is not a character in any stream. Trying to 'push' it back onto the
stream doesn't make sense.

Given..
int ch;
ch = getc(pfile);
if (ch == EOF)
{
/* Assuming no error, getting here means the the previous call to
getc(pfile) was the last character in the stream.
*/
}

i read a float in the stream "2."
this is what i have to do (in the side stream only)

int ch1, ch2, ch3;
ch1=getc(stream ); // ch1='2'
ch2=getc(stream ); // ch2="."
ch3=getc(stream ); // ch3=EOF
ungetc(EOF);
ungetc(ch2);
because "." is not in the number so it seems i have to reput it in the
stream;
but the stream is eof so i have to erase eof
but in a std-input stream if i erase eof getc() continue to ask chars

it seems i have an easy soultion for above with a little change to
ungetc() code (ungetc(EOF, pf) if the stream is EOF set a bit in
pf->flag and unset _EOF bit. fillbuf see that bit and turn it in _eof)

[Walter Roberson]

In article <tl************ *************** *****@4ax.com>, av <[e-mail] e:

>int ch1, ch2, ch3;
ch1=getc(strea m); // ch1='2'
ch2=getc(strea m); // ch2="."
ch3=getc(strea m); // ch3=EOF
ungetc(EOF);
ungetc(ch2);

The C standard only promises a single character of push-back; any
more than that is a system-dependant extension.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

[Herbert Rosenau]

On Tue, 18 Jul 2006 05:16:48 UTC, av <[e-mail] e:

>
int ch1, ch2, ch3;
ch1=getc(stream ); // ch1='2'
ch2=getc(stream ); // ch2="."
ch3=getc(stream ); // ch3=EOF
ungetc(EOF);
ungetc(ch2);

You can't unget more than one char.
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!