which functions set the end-of-file indicator?

[nicolas.sitbon]

Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached, but in C99 standard, I find p 288 (ISO/IEC 9899:TC3
Committee Draft — Septermber 7, 2007 WG14/N1256)

/* ============================= */
#include <stdio.h>
/* ... */
int count; float quant; char units[21], item[21];
do {
count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
fscanf(stdin,"%*[^\n]");
} while (!feof(stdin) && !ferror(stdin));
/* ============================= */
It seems to say that fscanf family function set end-of-file indicator
too? which functions set the end-of-file indicator?

[vippstar]

On Aug 4, 9:05 pm, [e-mail] wrote:
<snip>

It seems to say that fscanf family function set end-of-file indicator
too? which functions set the end-of-file indicator?

All functions that perform IO operations. (ie even perror() can set
the 'error' indicator for stderr if an error occurs at writing)

[Malcolm McLean]

<ni************@gmail.comwrote in message news:

>Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached.

The book is wrong, at least to all intents and purposes. EOF will be
returned after the contents of the file have been exhausted by any of the
read functions. feof() returns true after the first read to return EOF.

I think what he is thinking is that if a call to a function like fscanf()
doesn't match the input format than you'll get a partial read - the function
will return the number of arguments successfully converted - and EOF may not
be set, even if you are very close to the end of the file and have no
complete records left.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Eric Sosman]

ni************@gmail.com wrote:

Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached, but in C99 standard, I find p 288 (ISO/IEC 9899:TC3
Committee Draft — Septermber 7, 2007 WG14/N1256)

/* ============================= */
#include <stdio.h>
/* ... */
int count; float quant; char units[21], item[21];
do {
count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
fscanf(stdin,"%*[^\n]");
} while (!feof(stdin) && !ferror(stdin));
/* ============================= */
It seems to say that fscanf family function set end-of-file indicator
too? which functions set the end-of-file indicator?

Any function that tries to read from a stream can set the
end-of-file indicator for that stream. The fopen(), freopen(),
clearerr(), ungetc(), fseek(), rewind(), and fsetpos() functions
can clear it (I think that's all, but it's possible I've overlooked
a few). No other functions modify the end-of-file indicator --
except that, as always, there's no telling what might happen if
the program invokes undefined behavior.

--
Er*********@sun.com

[Chris Torek]

In article <27**********************************@k13g2000hse. googlegroups.com>
<ni************@gmail.comwrote:

>Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached ...

This is incorrect. In the "obviously wrong" part, putc() is not
going to set the end-of-file indicator, for instance. :-) But it
is still wrong, and perhaps overly complicated.

All I/O is done "as if" via fgetc() and fputc(). If fgetc() would
have set the end-of-file indicator, any other input-oriented
operation that would have called fgetc() must also set the e-o-f
indicator. (And of course, if fgetc() would have set the error
indicator, any other input-oriented operation that would have called
fgetc() must also set the error indicator. The "would have"s here
simply mean that, deep inside the implementation, scanf() or fread()
or whatever might use something "faster" or "better" than an actual
call to fgetc(), such as an inline expansion of what fgetc() does.
But if they do avoid fgetc() in favor of something "better", they
still have to act *as if* they had made an actual call to fgetc(),
including setting the e-of-f and/or error indicators in the same
way that fgetc() would have.)

(For instance, an implementation might have a macro like this:

#define fast_inlined_getc(f) \
((f)->_readcount 0 ? --(f)->_readcount, *(f)->_readptr++ : \
fgetc(f))

and it could then use this in the scanf engine. The fgets() and
fread() functions might look directly at f->_readcount:

int fgets(char *buf, size_t bufsize, FILE *stream) {
...
p = memchr(f->_readptr, '\n', min(f->_readsize, room_in_user_buffer));
if (p != NULL) {
/*
* Found entire input line in current buffer. Do a quick
* copy-and-take.
*/
line_len = p - f->_readptr; /* length of the line */
memcpy(buf, f->_readptr, line_len); /* copy it */
f->_readptr += line_len; /* and take it out */
f->_readsize -= line_len; /* of the stdio buffer */
} else {
/*
* Found only part of line in current buffer, or buffer
* is empty. Do whatever is required to copy partial
* line (if any) and read more input, in a loop as needed.
*/
...
}
...
}

At some point, though, these all call fgetc() (or the underlying
code that implements fgetc()) to refill the stdio buffer. It is
this code that handles "read from underlying file or device"
requests, and it is this "read from underlying file or device"
request that encounters the kinds of failures that set the end-of-file
and/or error indicators.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[nicolas.sitbon]

OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

[santosh]

ni************@gmail.com wrote:

OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

Here you go:

<http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=29237>

[Eric Sosman]

ni************@gmail.com wrote:

OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

Unless the post hasn't reached my news server yet, nobody has
claimed that all I/O functions can set or clear the end-of-file
indicator. putc(), for example, cannot. Nor can ftell(), nor
setvbuf(), nor feof(), nor a bunch of others.

All *input* functions are able to set the end-of-file indicator.
Some specified functions (the list I posted earlier, plus ungetwc() --
I warned you I might have missed a few) -- can clear the indicator.
Other functions leave it alone, barring undefined behavior.

The normative reference is section 7.19 of the Standard.

--
Er*********@sun.com

[santosh]

Eric Sosman wrote:

ni************@gmail.com wrote:

>OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

Unless the post hasn't reached my news server yet, nobody has
claimed that all I/O functions can set or clear the end-of-file
indicator. putc(), for example, cannot. Nor can ftell(), nor
setvbuf(), nor feof(), nor a bunch of others.

To quote vippstar:

All functions that perform IO operations. (ie even perror() can set
the 'error' indicator for stderr if an error occurs at writing)

A bit of an overstatement, but this happens in ordinary speech. We can't
all expect be like Keith!

<snip>

[nicolas.sitbon]

On 4 août, 21:30, Eric Sosman <[e-mail]:

[e-mail] wrote:

OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

* * *The normative reference is section 7.19 of the Standard.

--
[e-mail]

I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!

[santosh]

ni************@gmail.com wrote:

On 4 août, 21:30, Eric Sosman <[e-mail]:

>[e-mail] wrote:

OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99
says that all I/O functions can set/clear end-of-file indicator!!!

The normative reference is section 7.19 of the Standard.

I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!

Hasn't it been made clear to you by now that only one poster has said
that all functions that perform an I/O operation set these flags, and
that he was overstating his case, as has been explained more than once?

[nicolas.sitbon]

On 4 août, 21:59, santosh <[e-mail]:

[e-mail] wrote:

On 4 août, 21:30, Eric Sosman <[e-mail]:

[e-mail] wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99
says that all I/O functions can set/clear end-of-file indicator!!!

The normative reference is section 7.19 of the Standard.

I looked at this section, but I didn't find anything saying clearly
that all IO INPUT functions set/clear the end-of-file indicator!

Hasn't it been made clear to you by now that only one poster has said
that all functions that perform an I/O operation set these flags, and
that he was overstating his case, as has been explained more than once?

read what I said : all IO INPUT functions

[santosh]

ni************@gmail.com wrote:

On 4 août, 21:59, santosh <[e-mail]:

>[e-mail] wrote:

On 4 août, 21:30, Eric Sosman <[e-mail]:
[e-mail] wrote:
OK OK, everybody seems to be ok to say that all I/O functions
can potentially set/clear the end-of-file indicator, but nobody
give me normative reference, and the author says that nothing in
the C99 says that all I/O functions can set/clear end-of-file
indicator!!!

>The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO INPUT functions set/clear the end-of-file indicator!

Hasn't it been made clear to you by now that only one poster has said
that all functions that perform an I/O operation set these flags, and
that he was overstating his case, as has been explained more than
once?

read what I said : all IO INPUT functions

You have already been told that all input in C is done as if it is
composed of one or more calls to fgetc, and fgetc can most certainly
set the end-of-file indicator, and it's implied that other input
functions modelled on top of it, must also do so. Indeed they have no
choice but to do so. However they do have different methods of
notifying the user of such an exception. For example fgets returns a
null pointer, fread returns a short item count, scanf returns EOF etc.
In all cases you can always determine whether a particular FILE stream
is at end-of-file by calling the feof function, and whether an I/O
error has occurred during the last access by using the ferror function.

[Eric Sosman]

santosh wrote:

Eric Sosman wrote:

>ni************@gmail.com wrote:

>>OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

Unless the post hasn't reached my news server yet, nobody has
claimed that all I/O functions can set or clear the end-of-file
indicator. putc(), for example, cannot. Nor can ftell(), nor
setvbuf(), nor feof(), nor a bunch of others.

To quote vippstar:

All functions that perform IO operations. (ie even perror() can set
the 'error' indicator for stderr if an error occurs at writing)

The O.P. asked about the end-of-file indicator. The end-of-file
indicator and the error indicator are separate indicators, and are
set and cleared under different circumstances.

--
Er*********@sun.com

[jameskuyper]

[e-mail] wrote:

On 4 ao�t, 21:30, Eric Sosman <[e-mail]:

...

� � �The normative reference is section 7.19 ofthe Standard.

--
[e-mail]

I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!

It doesn't explain it in those terms. You have to follow several
intermediate steps.

7.19.7.1p3 says that fgetc() sets the end-of-file indicator.
7.24.3.1p3 says the same for fgetwc(). All wide character input
functions have their behavior defined in terms of successive calls to
fgetwc(), and all byte input functions have their behavior defined in
terms of repeated calls to fgetc() (7.19.3p11). All of the input
functions are defined as either wide character input functions or byte
input functions (7.19.1p3) . Those functions don't have to actually
call fgetc()/fgetwc(), but must produce the same behavior as if they
called fgetc()/fgetwc(), which means that they must set the end-of-
file indicator, when appropriate.

[nicolas.sitbon]

On 4 août, 22:14, santosh <[e-mail]:

[e-mail] wrote:

On 4 août, 21:59, santosh <[e-mail]:

[e-mail] wrote:
On 4 août, 21:30, Eric Sosman <[e-mail]:
[e-mail] wrote:
OK OK, everybody seems to be ok to say that all I/O functions
can potentially set/clear the end-of-file indicator, but nobody
give me normative reference, and the author says that nothing in
the C99 says that all I/O functions can set/clear end-of-file
indicator!!!

The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO INPUT functions set/clear the end-of-file indicator!

Hasn't it been made clear to you by now that only one poster has said
that all functions that perform an I/O operation set these flags, and
that he was overstating his case, as has been explained more than
once?

read what I said : all IO INPUT functions

You have already been told that all input in C is done as if it is
composed of one or more calls to fgetc, and fgetc can most certainly
set the end-of-file indicator, and it's implied that other input
functions modelled on top of it, must also do so. Indeed they have no
choice but to do so. However they do have different methods of
notifying the user of such an exception. For example fgets returns a
null pointer, fread returns a short item count, scanf returns EOF etc.
In all cases you can always determine whether a particular FILE stream
is at end-of-file by calling the feof function, and whether an I/O
error has occurred during the last access by using the ferror function.

sorry but, one more time, you don't answer me : can you say precisely,
where in the normative reference it is write that all IO INPUT
functions clear/set the end-of-file indicator cause if I write to the
author without any proof...

[santosh]

Eric Sosman wrote:

santosh wrote:

>Eric Sosman wrote:

>>ni************@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99
says that all I/O functions can set/clear end-of-file indicator!!!
Unless the post hasn't reached my news server yet, nobody has
claimed that all I/O functions can set or clear the end-of-file
indicator. putc(), for example, cannot. Nor can ftell(), nor
setvbuf(), nor feof(), nor a bunch of others.

To quote vippstar:

All functions that perform IO operations. (ie even perror() can set
the 'error' indicator for stderr if an error occurs at writing)

The O.P. asked about the end-of-file indicator. The end-of-file
indicator and the error indicator are separate indicators, and are
set and cleared under different circumstances.

You're right. Apologies to vippstar for misquoting him.

[Eric Sosman]

ni************@gmail.com wrote:

On 4 août, 21:30, Eric Sosman <[e-mail]:

>[e-mail] wrote:

>>OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

The normative reference is section 7.19 of the Standard.

I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!

It's in the same paragraph that says the Moon is made of
green cheese. In other words, the Standard says no such thing:
You are searching for the normative text of a falsehood.

Is it possible that you have confused the end-of-file
indicator with the error indicator? They are not the same.

--
Er*********@sun.com

[nicolas.sitbon]

On 4 août, 22:28, Eric Sosman <[e-mail]:

* * *Is it possible that you have confused the end-of-file
indicator with the error indicator? *They are not the same.

--
[e-mail]

In fact, the author says that except the functions I mentioned above,
all other are not guaranteed to set the end-of-file OR error
indicator, and he says that other functions are not portable if used
in this way. For french programmers who want to verify my saying, the
book is "méthodologie de la programmation en C, norme C99, API POSIX"
de Achille Braquelaire.

[Eric Sosman]

Eric Sosman wrote:

ni************@gmail.com wrote:

>On 4 août, 21:30, Eric Sosman <[e-mail]:

>>[e-mail] wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

The normative reference is section 7.19 of the Standard.

I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!

It's in the same paragraph that says the Moon is made of
green cheese. In other words, the Standard says no such thing:
You are searching for the normative text of a falsehood.

Is it possible that you have confused the end-of-file
indicator with the error indicator? They are not the same.

Pardon me; I overlooked the insertion of the word "input" in
your restatement of the question. Yes, the Standard says that all
input functions can set the end-of-file indicator, but it says so
in the descriptions of the individual functions, not as a blanket
statement about all input functions. (Indeed, the Standard never
defines "input functions" as such, although it does define some
close relatives.)

If we take the commonsense view that "input functions" are the
"wide character input functions" (7.19.1p5) plus fgetc, fgets, fread,
fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf, I believe
that the description of each says it can set the end-of-file
indicator. (I haven't checked, but you're welcome to -- and
maybe to file a Defect Report if any of them forgets to!) You can
also search the function descriptions for those that clear or can
clear the end-of-file indicator; it would be somewhat clumsier to
make a blanket statement about the latter category.

--
Er*********@sun.com

[jameskuyper]

Eric Sosman wrote:
....

statement about all input functions. (Indeed, the Standard never
defines "input functions" as such, although it does define some
close relatives.)

If we take the commonsense view that "input functions" are the
"wide character input functions" (7.19.1p5) ...

Which starts out saying "The input/output functions are given the
following collective terms"

... plus fgetc, fgets, fread,
fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf,

All of which fall into the category defined by 7.19.1p5 as "byte input/
output functions".

The standard may fail to distinguish between byte input and byte
output functions, but is anyone seriously in doubt as to which of the
byte input/output functions are input functions, and which ones are
output functions?

... I believe
that the description of each says it can set the end-of-file
indicator. (I haven't checked, but you're welcome to -- and

I have. The ones that process more than one character at a time don't
say so directly. You have to invoke 7.19.3p11 to determine that they
are also required to set it.

[Eric Sosman]

ja*********@verizon.net wrote:

Eric Sosman wrote:
...

>statement about all input functions. (Indeed, the Standard never
defines "input functions" as such, although it does define some
close relatives.)

If we take the commonsense view that "input functions" are the
"wide character input functions" (7.19.1p5) ...

Which starts out saying "The input/output functions are given the
following collective terms"

>... plus fgetc, fgets, fread,
fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf,

All of which fall into the category defined by 7.19.1p5 as "byte input/
output functions".

The standard may fail to distinguish between byte input and byte
output functions, but is anyone seriously in doubt as to which of the
byte input/output functions are input functions, and which ones are
output functions?

I'd say that's the commonsense view. In fact, I *did* say
that's the commonsense view. Not sure what the argument's about ...

--
Er*********@sun.com

[nicolas.sitbon]

On 4 août, 22:48, Eric Sosman <[e-mail]:

Eric Sosman wrote:

[e-mail] wrote:

On 4 août, 21:30, Eric Sosman <[e-mail]:
[e-mail] wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

>* * *The normative reference is section 7.19 of the Standard.

I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!

* * It's in the same paragraph that says the Moon is made of
green cheese. *In other words, the Standard says no such thing:
You are searching for the normative text of a falsehood.

* * Is it possible that you have confused the end-of-file
indicator with the error indicator? *They are not the same.

* * *Pardon me; I overlooked the insertion of the word "input" in
your restatement of the question. *Yes, the Standard says that all
input functions can set the end-of-file indicator, but it says so
in the descriptions of the individual functions, not as a blanket
statement about all input functions. *(Indeed, the Standard never
defines "input functions" as such, although it does define some
close relatives.)

* * *If we take the commonsense view that "input functions" are the
"wide character input functions" (7.19.1p5) plus fgetc, fgets, fread,
fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf, I believe
that the description of each says it can set the end-of-file
indicator. *(I haven't checked, but you're welcome to -- and
maybe to file a Defect Report if any of them forgets to!) *You can
also search the function descriptions for those that clear or can
clear the end-of-file indicator; it would be somewhat clumsier to
make a blanket statement about the latter category.

--
[e-mail]

I checked and for example, the fscanf function, nothing says that it
sets the end-of-file indicator except perhaps this example :

#include <stdio.h>
/* ... */
int count; float quant; char units[21], item[21];
do {
count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
fscanf(stdin,"%*[^\n]");
} while (!feof(stdin) && !ferror(stdin));

[Barry Schwarz]

On Mon, 4 Aug 2008 12:50:23 -0700 (PDT), ni************@gmail.com
wrote:

>On 4 août, 21:30, Eric Sosman <[e-mail]:

>[e-mail] wrote:

OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

* * *The normative reference is section 7.19 of the Standard.

--
[e-mail]

I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!

Since it is obviously false, you shouldn't. Read 7.19.3-11 followed
by 7.19.7.1-3 to learn when it is set. You should then be able to
find on your own when it is cleared.

--
Remove del for email

[nicolas.sitbon]

On 4 août, 22:58, [e-mail] wrote:

Eric Sosman wrote:
I have. The ones that process more than one character at a time don't
say so directly. You have to invoke 7.19.3p11 to determine that they
are also required to set it.

11 The wide character input functions read multibyte characters from
the stream and convert
them to wide characters as if they were read by successive calls to
the fgetwc function.
Each conversion occurs as if by a call to the mbrtowc function,
with the conversion state
described by the stream’s own mbstate_t object. The byte input
functions read
characters from the stream as if by successive calls to the fgetc
function.
Many thanks to everybody, this time it's clear for me.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 04 Aug 2008 14:06:55 -0700, nicolas.sitbon wrote:

I checked and for example, the fscanf function, nothing says that it
sets the end-of-file indicator

Okay, maybe an example is clearer for you.

7.19.1p5 (Input/output <stdio.h>; Introduction)
"The byte input/output functions [...]: [...], fscanf, [...]"

7.19.3p11 (Files)
"The byte input functions read characters from the stream as if by
successive calls to the fgetc function."

7.19.7.1p3 (The fgetc function)
"If [...] the stream is at end-of-file, the end-of-file indicator for the
stream is set [...]"

Yes, it doesn't explicitly say that fscanf sets the end-of-file indicator.
But a conforming implementation where fscanf *doesn't* set the end-of-file
indicator cannot exist; it would have to break one of these three
requirements. Either it doesn't classify fscanf as a byte input function,
or it doesn't make byte input functions read input as if by successive
calls to fgetc, or it doesn't make fgetc set the end-of-file indicator.

[Flash Gordon]

Malcolm McLean wrote, On 04/08/08 19:27:

>
<ni************@gmail.comwrote in message news:

>Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached.

The book is wrong, at least to all intents and purposes. EOF will be
returned after the contents of the file have been exhausted by any of
the read functions. feof() returns true after the first read to return EOF.

The above is at least misleading. EOF is a macro which evaluates to an
integer constant. Since some of the input functions return pointers you
are obviously wrong about all of the input functions being able to
return its value. Also for those which can return EOF they can do so
because of an error, and if it is an error causing the routine to return
EOF then feof() will not return true but ferror() will.

I think what he is thinking is that if a call to a function like
fscanf() doesn't match the input format than you'll get a partial read -
the function will return the number of arguments successfully converted
- and EOF may not be set, even if you are very close to the end of the
file and have no complete records left.

Well, that appears to not be what the OP's book was referring to, but it
is true.
--
Flash Gordon

[Greg Comeau]

In article <50**********************************@f63g2000hsf. googlegroups.com>,
<ni************@gmail.comwrote:

>OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

All I/O function don't, for instance, I seem to recal ferror() does not,
although you may argue that that call does not do any real I/O even though
it is in the I/O family. Also, some involve WEOF.

However, C99 specifically mentions which routines return EOF et al,
and that's a real lot of them.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <1217878106.929229@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:

>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[vippstar]

On Aug 5, 3:40 am, [e-mail] (Greg Comeau) wrote:

In article <1217878106.929229@news1nwk>,
Eric Sosman <[e-mail]:

... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.

The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

Mr Sosman is talking about file streams that feof() returns non-zero
for. (ie the eof flag is set).
putc cannot set that flag.

[Greg Comeau]

In article <g7**********@panix3.panix.com>,
Greg Comeau <co****@comeaucomputing.comwrote:

>In article <1217878106.929229@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:

>>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.

Oops, we're definitely using different words,
so while what I wrote is true, you were clearly talking
about something else.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Keith Thompson]

co****@panix.com (Greg Comeau) writes:

In article <1217878106.929229@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:

>>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.

Certainly.

Returning EOF and setting the end-of-file indicator are two different
things.

Concretely:

before = feof(stdout);
putc_result = putc('x');
after = feof(stdout);

It can be the case that putc_result == EOF, but it cannot be the case
that before==0 and after!=0.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Greg Comeau wrote:

Eric Sosman <Er*********@sun.comwrote:

>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.

Returning EOF signals error, not setting of end-of-file indicator.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Barry Schwarz]

On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vi******@gmail.com wrote:

>On Aug 5, 3:40 am, [e-mail] (Greg Comeau) wrote:

>In article <1217878106.929229@news1nwk>,
Eric Sosman <[e-mail]:

>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.

The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

>
Mr Sosman is talking about file streams that feof() returns non-zero
for. (ie the eof flag is set).
putc cannot set that flag.

--
Remove del for email

[santosh]

Barry Schwarz wrote:

On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vi******@gmail.com wrote:

>>On Aug 5, 3:40 am, [e-mail] (Greg Comeau) wrote:

>>In article <1217878106.929229@news1nwk>,
Eric Sosman <[e-mail]:

... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.

The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

And here is a test program as well:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
int retval = 0, rc = 0;
puts("Writing EOF to stderr with putc...");
retval = putc(EOF, stderr);
if (retval == EOF) {
printf("\nputc returned EOF. Value is: %d\n", retval);
if (ferror(stderr)) {
puts("Error indicator for stderr set.");
rc = EXIT_FAILURE;
}
} else printf("\nputc returned: %d\n", retval);
return rc;
}

$ ./a.out
Writing EOF to stderr with putc...
?
putc returned: 255
$

[vippstar]

On Aug 5, 11:44 am, Barry Schwarz <[e-mail]:

On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), [e-mail] wrote:

<snip>

The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

google thread
<http://groups.google.com/group/comp....thread/thread/
9047fe9cc86e1c6a/d5b9489e0b16a415>
or use the message id
<c9**********************************@e39g2000hsf. googlegroups.com>

[vippstar]

On Aug 5, 12:35 pm, santosh <[e-mail]:

Barry Schwarz wrote:

On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), [e-mail] wrote:

>On Aug 5, 3:40 am, [e-mail] (Greg Comeau) wrote:
In article <1217878106.929229@news1nwk>,
Eric Sosman <[e-mail]:

>... set ... the end-of-file
indicator. putc(), for example, cannot.

>Dunno if we're using different words or not, but
putc certainly can return EOF.

>The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

And here is a test program as well:

<snip>

Test programs like this are meaningless.
It's like claiming that CHAR_BIT is 8 and then writing a test program
to back up the claim...
See my response to Mr Schwarz about EOF and putc.

[santosh]

vi******@gmail.com wrote:

On Aug 5, 11:44 am, Barry Schwarz <[e-mail]:

>On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), [e-mail] wrote:

<snip>

>The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

google thread
<http://groups.google.com/group/comp....thread/thread/
9047fe9cc86e1c6a/d5b9489e0b16a415>
or use the message id
<c9**********************************@e39g2000hsf. googlegroups.com>

Are you specifically claiming that a call to fputc/putc with EOF as it's
first argument will return EOF if a call to ferror on the stream
immediately after the fputc/putc call returns zero?

[CBFalconer]

vi******@gmail.com wrote:

>

.... snip ...

>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Heathfield]

CBFalconer said:

vi******@gmail.com wrote:

>>

... snip ...

>>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>vi******@gmail.com wrote:

>>>

... snip ...

>>>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[santosh]

CBFalconer wrote:

Richard Heathfield wrote:

>CBFalconer said:

>>vi******@gmail.com wrote:

... snip ...

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.

That's impossible and makes no sense too.

The issue here is whether it makes sense to pass EOF to fputc or putc.
As they take an int expression for their first arguments, it is
possible to do so. That value is then converted inside [f]putc to an
unsigned char value and written to the stream specified. Then this byte
is cast to int and returned, if there are no write errors, in which
case EOF is returned.

I think the issue is whether both of these two (simplified)
implementations of fputc are correct, as per the Standard:

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return (unsigned char)ch;
else { s->err_flag = 1; return EOF; }
}

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return ch;
else { s->err_flag = 1; return EOF; }
}

I think that the Standard doesn't allow the second implementation. The
relevant part is 7.19.7.3 of n1256.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Richard Heathfield wrote:

>CBFalconer said:

>>vi******@gmail.com wrote:

... snip ...

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.

You just need an implementation where sizeof(int)==1 (which implies
CHAR_BIT>=16). (I'm ignoring the possibility of padding bits.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Barry Schwarz]

5On Tue, 5 Aug 2008 05:32:36 -0700 (PDT), vi******@gmail.com wrote:

>On Aug 5, 11:44 am, Barry Schwarz <[e-mail]:

>On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), [e-mail] wrote:

<snip>

>The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

It will never return EOF as the value of the byte written. That is
what you claimed as the second case and it cannot be. More to the
point, putc will never write a negative value since each byte is
converted to unsigned char. Read the second section of the standard I
reference above.

--
Remove del for email

[vippstar]

On Aug 5, 8:23 pm, Barry Schwarz <[e-mail]:

5On Tue, 5 Aug 2008 05:32:36 -0700 (PDT), [e-mail] wrote:

On Aug 5, 11:44 am, Barry Schwarz <[e-mail]:

On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), [e-mail] wrote:

<snip>

The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

It will never return EOF as the value of the byte written. That is
what you claimed as the second case and it cannot be. More to the
point, putc will never write a negative value since each byte is
converted to unsigned char. Read the second section of the standard I
reference above.

I'm not convinced. Read the discussion in my message that you snipped.
I don't think you understand the situation I'm talking about.

[Eric Sosman]

Barry Schwarz wrote:

>
No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

Not even when CHAR_MIN<=EOF and UCHAR_MAX>INT_MAX?

--
Er*********@sun.com

[CBFalconer]

santosh wrote:

CBFalconer wrote:

>Richard Heathfield wrote:

>>CBFalconer said:
vi******@gmail.com wrote:
>
... snip ...
>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.

That's impossible and makes no sense too.

The issue here is whether it makes sense to pass EOF to fputc or
putc. As they take an int expression for their first arguments, it
is possible to do so. That value is then converted inside [f]putc
to an unsigned char value and written to the stream specified.
Then this byte is cast to int and returned, if there are no write
errors, in which case EOF is returned.

Nit time. Your analysis is flawed. Notice that in the prototype:

int fputc(int ch, FILE *f);

ch is defined as an int. The conversion to int occurs before the
function is called. So fputc never sees a ch, and never converts
any such.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Heathfield]

CBFalconer said:

santosh wrote:

<snip>

>The issue here is whether it makes sense to pass EOF to fputc or
putc. As they take an int expression for their first arguments, it
is possible to do so. That value is then converted inside [f]putc
to an unsigned char value and written to the stream specified.
Then this byte is cast to int and returned, if there are no write
errors, in which case EOF is returned.

Nit time. Your analysis is flawed. Notice that in the prototype:

int fputc(int ch, FILE *f);

ch is defined as an int. The conversion to int occurs before the
function is called. So fputc never sees a ch, and never converts
any such.

santosh claimed that, inside [f]putc, the value is converted /to an
unsigned char value/, and that is a perfectly correct claim.

Proof (C89): 4.9.7.3 The fputc function

Synopsis

#include <stdio.h>
int fputc(int c, FILE *stream);

Description

The fputc function writes the character specified by c (converted
to an unsigned char )

Proof (C99): 7.19.7.3 The fputc function
Synopsis
1 #include <stdio.h>
int fputc(int c, FILE *stream);
Description
2 The fputc function writes the character specified by c (converted to
an unsigned char)
You have incorrectly "corrected" santosh. In such circumstances, an apology
is traditional in this newsgroup.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>santosh wrote:

<snip>

>>The issue here is whether it makes sense to pass EOF to fputc or
putc. As they take an int expression for their first arguments, it
is possible to do so. That value is then converted inside [f]putc
to an unsigned char value and written to the stream specified.
Then this byte is cast to int and returned, if there are no write
errors, in which case EOF is returned.

Nit time. Your analysis is flawed. Notice that in the prototype:

int fputc(int ch, FILE *f);

ch is defined as an int. The conversion to int occurs before the
function is called. So fputc never sees a ch, and never converts
any such.

santosh claimed that, inside [f]putc, the value is converted /to an
unsigned char value/, and that is a perfectly correct claim.

.... trim justification ...

>
You have incorrectly "corrected" santosh. In such circumstances, an apology
is traditional in this newsgroup.

Alright. Apology tendered. It WAS a nit.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Barry Schwarz]

On Tue, 05 Aug 2008 20:28:38 +0530, santosh <sa*********@gmail.com>
wrote:

>CBFalconer wrote:

>Richard Heathfield wrote:

>>CBFalconer said:
vi******@gmail.com wrote:
>
... snip ...
>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.

That's impossible and makes no sense too.

The issue here is whether it makes sense to pass EOF to fputc or putc.
As they take an int expression for their first arguments, it is
possible to do so. That value is then converted inside [f]putc to an
unsigned char value and written to the stream specified. Then this byte
is cast to int and returned, if there are no write errors, in which
case EOF is returned.

When the unsigned char is converted back to an int, the value must be
non-negative. In that case it cannot be EOF which is guaranteed to be
negative. In the absence of an error, only non-negative values will
be returned. EOF is only returned on error.

>
I think the issue is whether both of these two (simplified)
implementations of fputc are correct, as per the Standard:

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return (unsigned char)ch;
else { s->err_flag = 1; return EOF; }
}

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return ch;
else { s->err_flag = 1; return EOF; }
}

I think that the Standard doesn't allow the second implementation. The
relevant part is 7.19.7.3 of n1256.

Since you know this to be incorrect, then you know that the return
value will be non-negative in the absence of an error.

--
Remove del for email