problem with Data Files

[alice]

hi all,
What will happen when I tries to input a character from a file
which is finished, in other words what will 'c' contains after the last
statement in the following code is executed :

FILE * file =fopen("FILE1.c","r");
char c;
while((c=fgetc(file)) != EOF);
c=fgetc(file);
// what is value of c now???????????????????
Thanks,
Alice

[Lawrence Kirby]

On Tue, 18 Jan 2005 09:38:54 -0800, alice wrote:

hi all,
What will happen when I tries to input a character from a file
which is finished, in other words what will 'c' contains after the last
statement in the following code is executed :

FILE * file =fopen("FILE1.c","r");
char c;
while((c=fgetc(file)) != EOF);
This is incorrect, c needs to be defined as int. fgetc() returns int and
EOF is not guaranteed to be representable as a char. If it is it won't be
distinct from all possible char values.
c=fgetc(file);
// what is value of c now??????????????????? Thanks,

Probably EOF again, maybe something else if the end-of-file condition
cleared in the meantime. End-of-file condition can be sticky but it
doesn't have to be. If you want to attempt further file I/O after
end-of-file is indicated you should perform a file seek operation if that
is appropriate or else call clearerr(). You should not simply attempt
another read operation.

Lawrence

[bhanu]

EOF (-1)

[Ben Pfaff]

"bhanu" <go***********@hotmail.com> writes:

EOF (-1)

EOF is often -1 but that value is not guaranteed. EOF may be any
negative `int' value.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[pete]

alice wrote:

hi all,
What will happen when I tries to input a character from a file
which is finished,
in other words what will 'c' contains after the last
statement in the following code is executed :

FILE * file =fopen("FILE1.c","r");
char c;
while((c=fgetc(file)) != EOF);
c=fgetc(file);
// what is value of c now???????????????????

(char)EOF

--
pete

[bhanu]

Try this program: EOF is always -1, not any negative number.
#include <stdio.h>

int main()
{

FILE * file;
char c;

if((file=fopen("Test.txt","wb")) == NULL)
{
printf("error in opening the file");
return 0;
}

for(c = -10; c < 10; c++)
fputc(c, file);

fclose(file);

if((file=fopen("Test.txt","rb")) == NULL)
{
printf("error in opening the file");
return 0;
}

while((c=fgetc(file)) != EOF)
{
printf("\nc = %d", c);
}

c=fgetc(file);
printf("\n'c' After EOF = %d", c);

printf("\n");

fclose(file);
return 0;
}

Output:
c = -10
c = -9
c = -8
c = -7
c = -6
c = -5
c = -4
c = -3
c = -2
'c' After EOF = 0

[Mike Wahler]

"bhanu" <go***********@hotmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

Try this program: EOF is always -1,

It might be for a given compiler, it easily might not
be for others. The language imposes no requirement
that it be -1, only that it is an integer less than zero,
i.e. between INT_MIN and -1.

[snip code, which does not prove that EOF is always -1]

-Mike

[Ben Pfaff]

"bhanu" <go***********@hotmail.com> writes:

Try this program: EOF is always -1, not any negative number.

You cannot prove a statement about all C implementations by
demonstrating program on one implementation.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[CBFalconer]

alice wrote:

What will happen when I tries to input a character from a file
which is finished, in other words what will 'c' contains after
the last statement in the following code is executed :

FILE * file =fopen("FILE1.c","r");
char c;
while((c=fgetc(file)) != EOF);
c=fgetc(file);
// what is value of c now???????????????????

First of all c must be of type int, not char. EOF is outside the
range of chars. With that change, your final c will _probably_ be
EOF, since most disk files have what is called sticky eof. If the
input file happens to be a terminal, it may not have sticky EOF and
anything can happen.

Your code is more clearly written using "continue;" in place of the
raw ";" in the while loop, and the judicious use of blanks to
separate items improves readability.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Keith Thompson]

"bhanu" <go***********@hotmail.com> writes:

Try this program: EOF is always -1, not any negative number.

[snip]

C99 7.19.1p3, describing the standard header <stdio.h>, says:

The macros are
[...]
EOF

which expands to an integer constant expression, with type int and a
negative value, that is returned by several functions to indicate
end-of-file, that is, no more input from a stream;
[...]

The behavior of the program you posted is consistent with this. An
implementation with EOF==-2 or EOF==-20000 would also be consistent
with the standard.

(I'm assuming that your program correctly demonstrates that EOF==-1
for a given implementation; I haven't actually confirmed this.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

pete <pf*****@mindspring.com> writes:

alice wrote:

hi all,
What will happen when I tries to input a character from a file
which is finished,
in other words what will 'c' contains after the last
statement in the following code is executed :

FILE * file =fopen("FILE1.c","r");
char c;
while((c=fgetc(file)) != EOF);
c=fgetc(file);
// what is value of c now???????????????????

(char)EOF

If char is unsigned, the while() is an infinite loop (since c will
never have a negative value).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

alice wrote:

What will happen when I tries to input a character from a file
which is finished, in other words what will 'c' contains after
the last statement in the following code is executed :

FILE * file =fopen("FILE1.c","r");
char c;
while((c=fgetc(file)) != EOF);
c=fgetc(file);
// what is value of c now???????????????????

First of all c must be of type int, not char. EOF is outside the
range of chars. With that change, your final c will _probably_ be
EOF, since most disk files have what is called sticky eof. If the
input file happens to be a terminal, it may not have sticky EOF and
anything can happen.

EOF may be (and probably is) within the range of type char if char
happens to be signed, but that's beside the point. The value returned
by fgetc() is either an *unsigned* char converted to int, or EOF.

Figuring out what problems can occur when the result of fgetc() is
stored in a char is fairly complex (and is probably a good exercise
for an intermediate student). Fixing the code so you don't have to
worry about those problems in the first place is easy.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"bhanu" <go***********@hotmail.com> writes:

Try this program: EOF is always -1, not any negative number.

[snip]

Something else I've thought of:

The standard says that EOF expands to an integer constant expression,
with type int and a negative value. It doesn't say or imply that its
value is -1. But I'd be (mildly) surprised if there were any existing
implementation that has a value other than -1 for EOF. For one thing,
it can make the implementation of the functions in <ctype.h> a little
easier.

But well-written code won't break on a hypothetical implementation
with EOF==INT_MIN.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Torek]

In article <11*********************@f14g2000cwb.googlegroups. com>
bhanu <go***********@hotmail.com> wrote:

Try this program: EOF is always -1, not any negative number. [most of program snipped; but here are the key parts]char c;
while((c=fgetc(file)) != EOF)
{
printf("\nc = %d", c);
}

c=fgetc(file);
printf("\n'c' After EOF = %d", c);

I tried this and got:

c = 255
c = 255
c = 255
c = 255
c = 255
c = 255
... [output repeats forever]

Can you guess why? (Hint: I did not use an Intel 80x86. In fact,
I ran this on a PowerPC system.)

C guarantees that EOF is "#define"d in <stdio.h> as a negative
integer, but -1 is not required, just typical. (The implementation
I used, on which this demonstration program failed, does in fact
define EOF as -1, so that was not the problem.)

C does not guarantee that plain "char" is signed, and in this case,
it is not.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Keith Thompson wrote:

"bhanu" <go***********@hotmail.com> writes:

Try this program: EOF is always -1, not any negative number.

[snip]

Something else I've thought of:

The standard says that EOF expands to an integer constant expression,
with type int and a negative value. It doesn't say or imply that its
value is -1. But I'd be (mildly) surprised if there were any existing
implementation that has a value other than -1 for EOF. For one thing,
it can make the implementation of the functions in <ctype.h> a little
easier.

But well-written code won't break on a hypothetical implementation
with EOF==INT_MIN.

We should be able to confuse readers by replacing:

while (EOF != (ch = getchar()) {
/* process stuff */
}
with
while ((ch = getchar()) >= 0) {
/* process stuff */
}
or
do { /* much hairier, not input proof, assumes Ascii */
while ((ch = getchar()) > \'n') {
/* process stuff */
}
/* process eoln */
} while (ch >= 0);

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[junky_fellow]

Keith Thompson wrote:

"bhanu" <go***********@hotmail.com> writes:

Try this program: EOF is always -1, not any negative number. [snip]

Something else I've thought of:

The standard says that EOF expands to an integer constant expression,
with type int and a negative value. It doesn't say or imply that its
value is -1. But I'd be (mildly) surprised if there were any

existing implementation that has a value other than -1 for EOF. For one thing, it can make the implementation of the functions in <ctype.h> a little
easier.

Why there's a requirement to expand EOF to an integer constant (with
type
int and negative value) ? If we see the ASCII character set, the max
value
is 0x7f. So, we can easily represent EOF to be -1 (0xff). Why does the
standard expand EOF to integer type.

[Jonathan Burd]

bhanu wrote:

Try this program: EOF is always -1, not any negative number.
#include <stdio.h>

int main()
{

FILE * file;
char c;
Poof! Should be `int c;` EOF is an integer. And, as others pointed
out already, it may not be -1. ;)

Read this:
http://www.comsc.ucok.edu/~pcarter/f...rrors.html#4.1
if((file=fopen("Test.txt","wb")) == NULL)
{
printf("error in opening the file");
return 0;
}

for(c = -10; c < 10; c++)
fputc(c, file);

fclose(file);

if((file=fopen("Test.txt","rb")) == NULL)
{
printf("error in opening the file");
return 0;
}

while((c=fgetc(file)) != EOF)
{
printf("\nc = %d", c);
}

c=fgetc(file);
printf("\n'c' After EOF = %d", c);

printf("\n");

fclose(file);
return 0;
}

Output:
c = -10
c = -9
c = -8
c = -7
c = -6
c = -5
c = -4
c = -3
c = -2
'c' After EOF = 0

Where did you lose the indentation?

Regards,
Jonathan.

--
C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
C Library: http://www.dinkumware.com/refxc.html
C99 Standard Draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/

"I'm learning to program because then I can write
programs to do my homework faster." - Andy Anfilofieff

[Keith Thompson]

Jonathan Burd <jo***********@gmail.com> writes:
[...]

Where did you lose the indentation?

The new version of groups.google.com is buggy.

I posted about this here recently, subject "groups.google.com
indentation bugs [semi-OT]".

<http://groups-beta.google.com/group/comp.lang.c/msg/3ebf130c8b967899?dmode=source>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

ju**********@yahoo.co.in writes:

Keith Thompson wrote:

"bhanu" <go***********@hotmail.com> writes:

> Try this program: EOF is always -1, not any negative number.

[snip]

Something else I've thought of:

The standard says that EOF expands to an integer constant
expression, with type int and a negative value. It doesn't say or
imply that its value is -1. But I'd be (mildly) surprised if there
were any existing implementation that has a value other than -1 for
EOF. For one thing, it can make the implementation of the
functions in <ctype.h> a little easier.

Why there's a requirement to expand EOF to an integer constant (with
type int and negative value) ? If we see the ASCII character set,
the max value is 0x7f. So, we can easily represent EOF to be -1
(0xff). Why does the standard expand EOF to integer type.

-1 is an integer constant with type int and negative value.

If you're suggesting that EOF could be a character value, that
wouldn't work. The standard doesn't assume the ASCII character set;
there are conforming C implementations with different character sets.
And if you're reading a binary file, 0xff is a valid input value.

EOF has to be distinct from all possible character values. This is
done by having fgetc() return an int that's either an *unsigned* char
value converted to int, or EOF.

(The standard probably could have required EOF to be -1, rather than
any arbitrary negative value, but it didn't.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Eric Sosman]

Keith Thompson wrote:

The standard says that EOF expands to an integer constant expression,
with type int and a negative value. It doesn't say or imply that its
value is -1. But I'd be (mildly) surprised if there were any existing
implementation that has a value other than -1 for EOF. For one thing,
it can make the implementation of the functions in <ctype.h> a little
easier.

An implementation that defined EOF as the value of
CHAR_MIN-1 (or even SCHAR_MIN-1) could allow the <ctype.h>
implementation to be more tolerant of a common error.
Whether such tolerance is a good idea is debatable, but an
implementor might well have the goal of running as many
programs as possible with as little trouble as possible,
whether those programs are faulty or not. Market pressures
sometimes favor convenience over strictness.

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

[Richard Bos]

CBFalconer <cb********@yahoo.com> wrote:

We should be able to confuse readers by replacing:

while (EOF != (ch = getchar()) {
/* process stuff */
}
with do { /* much hairier, not input proof, assumes Ascii */
while ((ch = getchar()) > \'n') {

Assumes even more. It assumes no characters smaller than '\n' will
appear in the input. On ASCII systems on which '\n' equals 13, the page
feed character is smaller than it. I semi-regularly enter that character
at my console. I can also imagine people wanting to enter '\a', which on
an ASCII system is smaller than either option for '\n'.

Richard

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

CBFalconer <cb********@yahoo.com> wrote:

We should be able to confuse readers by replacing:

while (EOF != (ch = getchar()) {
/* process stuff */
}
with

do { /* much hairier, not input proof, assumes Ascii */
while ((ch = getchar()) > \'n') {

Assumes even more. It assumes no characters smaller than '\n' will
appear in the input. On ASCII systems on which '\n' equals 13, the page
feed character is smaller than it. I semi-regularly enter that character
at my console. I can also imagine people wanting to enter '\a', which on
an ASCII system is smaller than either option for '\n'.

All of which, I think, is already covered by "not input proof".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[lawrence.jones]

Lawrence Kirby <lk****@netactive.co.uk> wrote:

Probably EOF again, maybe something else if the end-of-file condition
cleared in the meantime. End-of-file condition can be sticky but it
doesn't have to be.

The C Standard has always required it to be sticky. Some (perhaps even
many) implementations still get it wrong.

-Larry Jones

I don't need to do a better job. I need better P.R. on the job I DO.
-- Calvin

[CBFalconer]

la************@ugs.com wrote:

Lawrence Kirby <lk****@netactive.co.uk> wrote:

Probably EOF again, maybe something else if the end-of-file
condition cleared in the meantime. End-of-file condition can be
sticky but it doesn't have to be.

The C Standard has always required it to be sticky. Some (perhaps
even many) implementations still get it wrong.

On stdin from the keyboard? On disk files I agree.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Lawrence Kirby]

On Thu, 20 Jan 2005 05:17:14 +0000, CBFalconer wrote:

la************@ugs.com wrote:

Lawrence Kirby <lk****@netactive.co.uk> wrote:

Probably EOF again, maybe something else if the end-of-file
condition cleared in the meantime. End-of-file condition can be
sticky but it doesn't have to be.
The C Standard has always required it to be sticky. Some (perhaps
even many) implementations still get it wrong.

It is one of those things that has been discussed at length in the past. I
agree that's how it should be, but the standard could be better worded.
FOr the error indicator too, it is certainly common practice to perform a
number of output operations and then test the error indicator at the end.
If it wasn't sticky that would be a problem. If the wording of the
standard is clear why do implementations still get it wrong? 7.17.1p2 says

"... an /error indicator/ that records whether a read/write error has
occurred, and an /end-of-file indicator/ that records whether the end of
the file has been reached"

I agree that that implies stickyness but it isn't quite definitive.
Something like

"... an /error indicator/ that is set when a read/write error occurs, and
an /end-of-file indicator/ that is set when the end of the file is
encountered"

This is more clearly a transition than a state of the file based
definition. Other parts of the standard state when the indicators are
cleared. I don't like "has been reached" because if you read 10 characters
from a file that contains 10 characters the end of the file has been
reached but I don't expect an implementation to set the end-of-file
indicator at that point (although it could), only for certain when a
subsequent read fails to get the data it asked for.
On stdin from the keyboard? On disk files I agree.

I don't see much distinction here.

1. Another program could extend the disk file after ours encountered
end-of-file.

2. There's no problem with the end-of-file or error indicators being
sticky on a stream attached to a keyboard. A correct C program should
call, for example, clearerr() if it wants to try to continue reading
from a stream where end-of-file has been indicated.

Lawrence

[Adrianp]

If you want to know the value of EOF on your compiler look in stdio.h (or
whatever io lib you are using). eg

#define EOF (-1)

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:Jk*****************@newsread3.news.pas.earthl ink.net...

"bhanu" <go***********@hotmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

Try this program: EOF is always -1,

It might be for a given compiler, it easily might not
be for others. The language imposes no requirement
that it be -1, only that it is an integer less than zero,
i.e. between INT_MIN and -1.

[snip code, which does not prove that EOF is always -1]

-Mike

[Mike Wahler]

"Adrianp" <ad******@adrian15.freeserve.co.uk> wrote in message
news:cs**********@newsg2.svr.pol.co.uk...

If you want to know the value of EOF
But there isn't any *need* to know. And often this
(compiler-specific) 'knowledge' can lead one to write
code which has problems if it is ported to another
compiler (or another version of the same one).

This is the whole point of having abstractions such
as 'EOF'. They weren't created just for fun.
on your compiler look in stdio.h (or
whatever io lib you are using). eg

#define EOF (-1)

or #define EOF (-42)

etc.

But there's no need to look this up (and as I noted above,
doing so can lead the ignorant to write unnecessarily
nonportable code).

Just write EOF and you have a guarantee (from the language
standard), that every compliant compiler will create code
that works correctly.

BTW Please don't top-post in comp.lang.c

-Mike