end-of-file problem

[Markus Pitha]

Hello,

I read a simple bmp-file with this loop:

while ( !feof(fp) ) {
printf("%x\n", fgetc(fp));
}
fclose(fp);

Everything seems to be correct, but at the end of the file, I get a weird
"ffffffff" output. How does this come? Actually the loop must have been
finished before printf can print some data, or when will the file
pointer increased in this case?


Thanks,
Markus

[boa]

Re: end-of-file problem

* Markus Pitha wrote, On 20.08.2006 15:01:

Hello,
>
I read a simple bmp-file with this loop:
>
while ( !feof(fp) ) {
printf("%x\n", fgetc(fp));
}
fclose(fp);
>
Everything seems to be correct,

It isn't, see the faq for details. http://c-faq.com/stdio/feof.html

but at the end of the file, I get a weird
"ffffffff" output. How does this come? Actually the loop must have been
finished before printf can print some data, or when will the file
pointer increased in this case?

ffffffff happens to be the same as -1 on most machines. EOF also happens
to be -1 on most machines. So you're printing the value of EOF, returned
from fgetc(). On the next iteration, feof() returns true and your loop
stops.

boa

>
>
Thanks,
Markus

[Markus Pitha]

Re: end-of-file problem

Hello,

thanks for the link but I couldn't handle it as in this example. I
got warnings of comparing pointers with NULL and therefore a bad program
behaviour like endless loops.
Now I decided to use the following construct:

fseek(fp, 0, SEEK_END);
filesize = ftell(fp);
rewind(fp);

while (ftell(fp) < filesize) {
printf("%x\n", fgetc(fp));
}
fclose(fp);

ffffffff happens to be the same as -1 on most machines.
to be -1 on most machines. So you're printing the value of EOF, returned
from fgetc(). On the next iteration, feof() returns true and your loop
stops.

Thanks, that sounds plausible to me.

[boa]

Re: end-of-file problem

* Markus Pitha wrote, On 20.08.2006 16:36:

Hello,
>
thanks for the link but I couldn't handle it as in this example. I
got warnings of comparing pointers with NULL and therefore a bad program
behaviour like endless loops.
Now I decided to use the following construct:
>
fseek(fp, 0, SEEK_END);
filesize = ftell(fp);
rewind(fp);
>
while (ftell(fp) < filesize) {
printf("%x\n", fgetc(fp));
}
fclose(fp);

Please don't.

How about something like this instead?
int c;

while( (c = fgetc(fp)) != EOF)
printf("%x\n"; c);


Boa

[snip]

[Markus Pitha]

Re: end-of-file problem

boa wrote:

while( (c = fgetc(fp)) != EOF)
printf("%x\n"; c);

I thought this is only allowed with text files because of the fact that
EOF is defined as -1 and binary files could contain "-1"?

[spibou@gmail.com]

Re: end-of-file problem

Markus Pitha wrote:

boa wrote:
>

while( (c = fgetc(fp)) != EOF)
printf("%x\n"; c);

>
I thought this is only allowed with text files because of the fact that
EOF is defined as -1 and binary files could contain "-1"?

No , it is allowed with all files. EOF will be defined in a
way that the value cannot appear in a file on your platform.

[Harald van Dijk]

Re: end-of-file problem

Markus Pitha wrote:

boa wrote:
>

> while( (c = fgetc(fp)) != EOF)
> printf("%x\n"; c);

>
I thought this is only allowed with text files because of the fact that
EOF is defined as -1 and binary files could contain "-1"?

fgetc() always returns either an unsigned char converted to int, or EOF. As
long as c is wide enough to hold both EOF and 0 ... UCHAR_MAX, for example
with c declared as int as it was in the message you replied to, there's no
problem. With c declared as char, there would be a problem.

[CBFalconer]

Re: end-of-file problem

Markus Pitha wrote:

>
I read a simple bmp-file with this loop:
>
while ( !feof(fp) ) {
printf("%x\n", fgetc(fp));
}
fclose(fp);
>
Everything seems to be correct, but at the end of the file, I get
a weird "ffffffff" output. How does this come? Actually the loop
must have been finished before printf can print some data, or when
will the file pointer increased in this case?

Nothing weird about it. It is simple misuse of the feof function.

int ch;

while (EOF != (ch = getc(fp)) {
printf("%x\n", fgetc(fp));
}
if (!feof(fp)) puts("Hardware error occured");

feof does not look forward, as in better languages. It
distinguishes between i/o errors and reaching EOF when an input
statement fails. To distinguish between EOF and all normal chars
it is necessary to receive those chars into an int, rather than a
char.

getc is normally preferable to fgetc when the file argument can be
evaluated more than once.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@mai neline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.netUSE maineline address!

[Markus Pitha]

Re: end-of-file problem

Harald van Dijk wrote:

fgetc() always returns either an unsigned char converted to int, or EOF. As
long as c is wide enough to hold both EOF and 0 ... UCHAR_MAX, for example
with c declared as int as it was in the message you replied to, there's no
problem. With c declared as char, there would be a problem.

I understand, thanks to everybody.


Markus

[Flash Gordon]

Re: end-of-file problem

CBFalconer wrote:

Markus Pitha wrote:

>I read a simple bmp-file with this loop:
>>
>while ( !feof(fp) ) {
> printf("%x\n", fgetc(fp));
>}
>fclose(fp);
>>
>Everything seems to be correct, but at the end of the file, I get
>a weird "ffffffff" output. How does this come? Actually the loop
>must have been finished before printf can print some data, or when
>will the file pointer increased in this case?

>
Nothing weird about it. It is simple misuse of the feof function.
>
int ch;
>
while (EOF != (ch = getc(fp)) {
printf("%x\n", fgetc(fp));

Did you really mean to read another character and print it, thereby
printing every other character? * think you meant:
printf("%x\n", ch);

}
if (!feof(fp)) puts("Hardware error occured");
>
feof does not look forward, as in better languages. It
distinguishes between i/o errors and reaching EOF when an input
statement fails. To distinguish between EOF and all normal chars
it is necessary to receive those chars into an int, rather than a
char.

Agreed.

getc is normally preferable to fgetc when the file argument can be
evaluated more than once.

I would say that it is extremely rare to need fgetc rather than getc. I
understand the code constructs which would require it, e.g.
fgetc(fparr[i++), I just can't think of anywhere where they would have
been useful to me. Has anyone here actually done something where they
had to use fgetc rather than getc?
--
Flash Gordon
Still sigless on this computer.

[Keith Thompson]

Re: end-of-file problem

Markus Pitha <ngNOSPAM@pitha x.netwrites:

boa wrote:

> while( (c = fgetc(fp)) != EOF)
> printf("%x\n"; c);

>
I thought this is only allowed with text files because of the fact that
EOF is defined as -1 and binary files could contain "-1"?

comp.lang.c FAQ, <http://www.c-faq.com/>, question 12.1.

--
Keith Thompson (The_Other_Keit h) kst-u@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.

[Bill Pursell]

Re: end-of-file problem


Markus Pitha wrote:

Hello,
>
thanks for the link but I couldn't handle it as in this example. I
got warnings of comparing pointers with NULL and therefore a bad program
behaviour like endless loops.
Now I decided to use the following construct:
>
fseek(fp, 0, SEEK_END);
filesize = ftell(fp);
rewind(fp);

This is slightly OT, but this particular technique is
really annoying. By doing this, you make it impossible
to run your program on anything but a regular file.
If you try to execute the code on a fifo or a stream
the seek will fail. You almost never need to know
the size of the file before you start processing. If
you do need to know it, you should find its size
using whatever mechanism is provided by your
platform (eg fstat()). Granted, if you do need to
know the file size, then it probably doesn't make
sense to run the program on a fifo or a stream,
but it's a really good idea to expect your program
to be modified at a later time to be used on an
input stream. For this example, (basically an
implementation of xxd), it is very easy to see someone
wanting to run it on a fifo and watching the output
as it progresses.

--
Bill Pursell

[Mark McIntyre]

Re: end-of-file problem

On Sun, 20 Aug 2006 15:36:38 +0000, in comp.lang.c , Markus Pitha
<ngNOSPAM@pitha x.netwrote:

>Hello,
>
>thanks for the link but I couldn't handle it as in this example. I
>got warnings of comparing pointers with NULL and therefore a bad program
>behaviour like endless loops.

Then why not ask about that problem, and maybe someone can help fix
it?

I get this all the time with users, asking the wrong question...

I can't login, can you reset my password to 'potato' please
your existing password isn't expired, did you try that?
I can't use it any more.
why not, its still valid?
I can't type it.
why not?
its got an 'e' in it
pardon, whys that a problem?
I poured coffee in my keyboard and the 'e' is broken, so I need a new
password....

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

Re: end-of-file problem

On Sun, 20 Aug 2006 15:57:38 +0000, in comp.lang.c , Markus Pitha
<ngNOSPAM@pitha x.netwrote:

>boa wrote:
>

> while( (c = fgetc(fp)) != EOF)
> printf("%x\n"; c);

>
>I thought this is only allowed with text files because of the fact that
>EOF is defined as -1 and binary files could contain "-1"?

NO. NO. NO. Do not confuse the EOF condition with the EOF character!

EOF is NOT a value read from the file, its a condition returned by the
library to indicate there's no more data. It works for any sort of
file (as long as itr has an end).
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Re: end-of-file problem

Mark McIntyre <markmcintyre@s pamcop.netwrite s:

On Sun, 20 Aug 2006 15:57:38 +0000, in comp.lang.c , Markus Pitha
<ngNOSPAM@pitha x.netwrote:
>

>>boa wrote:
>>

>> while( (c = fgetc(fp)) != EOF)
>> printf("%x\n"; c);

>>
>>I thought this is only allowed with text files because of the fact that
>>EOF is defined as -1 and binary files could contain "-1"?

>
NO. NO. NO. Do not confuse the EOF condition with the EOF character!

Better:

Do not confuse the end-of-file condition with the value of the EOF
macro.

EOF is NOT a value read from the file, its a condition returned by the
library to indicate there's no more data. It works for any sort of
file (as long as itr has an end).

End-of-file is a condition. EOF is a macro that expands to a value of
type int; this value is returned by certain library functions to
indicate that there's no more data, and it's distinct from any valid
character value (since EOF is negative, and a character read from a
file is interpreted as unsigned char and then converted to int).
getchar(), for example, returns the EOF value to indicate an
end-of-file (or error) condition.

--
Keith Thompson (The_Other_Keit h) kst-u@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.