A
av
Why is so danger to allow ungetc(EOF, pfile); (for close the imput
stream) ?
stream) ?
?
=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=
av said:
ungetc pushes characters back onto the stream, EOF isn't a character.
We already have fclose for closing a stream.
J
Joe Wright
av said:
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.
*/
}
P
P.J. Plauger
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
A
av
close in the way "pfile->flag|= _EOF;"
A
av
the above seems wrong
noone of you know if it is right "ungetc(EOF, pfile);"?
and for what it is intended to do?
P
P.J. Plauger
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
A
av
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)
W
Walter Roberson
The C standard only promises a single character of push-back; any
more than that is a system-dependant extension.
H
Herbert Rosenau
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!
A
av
if i do it, it means i can do it
ungetc set a flag in FILE if fail
K
Keith Thompson
av said:
Congratulations, that's simultaneously tautological and false.
Oh? What flag would that be?
C99 7.19.7.11p3:
One character of pushback is guaranteed. If the ungetc function is
called too many times on the same stream without an intervening
read or file positioning operation on that stream, the operation
may fail.
A failing ungetc() is indicated by a return value of EOF.
A
av
yes thank you, it seems i have forget this case and have correct my
code
now in my version of ungetc: ungetc_m()
if it not fail return the char of argument + carry flag ==0
if it fail return EOF carry flag set
so it seem agree with above standard
but so i can unget EOF too because i can see the carry flag that
ungetc_m return
then how it is "not standard" if i set a bit in the file->flag when i
can not unget a char (until EOF) ?
K
Keith Thompson
av said:
If "file" is a FILE*, attempting to refer to file->flag, or to any
member of *file, is non-portable. The standard says nothing about the
contents of type FILE; it needn't even be a structure.
If you're implementing your C library, of course, you can do anything
you like.
W
Walter Roberson
The contents of the FILE struct are not defined by the C standard,
so the flag field is not certain to exist.
You may also wish to consider whether your code would continue to
be correct if you were using POSIX threads: would you need to lock
the FILE structure before changing the flag ? (Thread locks are outside
of the C standard -- the point is more than what is inside of FILE
is implementation dependant and may have complications far beyond
the obvious.)
A
av
where is the problem? is it the file is open "for read" using a FILE*
"pf" in one thread and in some other thread i use the same "pf" for
read? and in what it can be useful?
for me the soultion is each thread has its FILE structure indipendent
from others threads