why can this code tell the EOF of binary file?

[chat]

Hi,
I know that text file ended with EOF mark but there is no mark for
binary file.
So, the problem is how do we know the end of binary file is reach?

This code can tell us when the end of file is reach

int ch;

FILE *fp;

fp = fopen("filename","rb");

if(fp != NULL) {
while((ch = getc(fp)) != EOF) {
/* your code */
}

}

My question is , since there is no ending mark up for binary file, why
does the code above work?
also, why does built-in function feof(fp) know where is end-of-file?
thank you for all discussions.
chat watchara

 

[Chris Dollin]

I know that text file ended with EOF mark but there is no mark for
binary file.

This is not true.

How a text /file/ ends isn't defined by the C standard. What /is/
defined is what happens when you try and read the postultimate
character of a FILE* [connected to a file] using (f)getc: you get
the magic value EOF. This is true whether or not you're reading
a "text file".

[However, this EOF may be preceeded by some number of 0's -- ISTR
it's zeroes -- not logically present in the file, because some
systems at some time did or still do not record the exact number
of bytes kept in a file: files may contain integral numbers of
/blocks/ of bytes.]

So, the problem is how do we know the end of binary file is reach?

Wait for EOF.

also, why does built-in function feof(fp) know where is end-of-file?

Because it's its business to know [that the last read failed because
it was at end-of-file]. Note that `feof` is often the wrong function
to be calling.

 

[Hallvard B Furuseth]

I know that text file ended with EOF mark but there is no mark for
binary file.
So, the problem is how do we know the end of binary file is reach?

A file in a file system normally has an associated file size which gives
the file's physical size in the file system. That may be a size in
bytes, in which case no "EOF mark" is needed to mark the end of text
files. But if the size is in blocks, then a binary file has a size
which is a multiple of the block size. (So does a text file as far as
the associatead file size is concerned, but an "EOF mark" can delimit it
before the end of physical file.)

(...)
fp = fopen("filename","rb");
if(fp != NULL) {
while((ch = getc(fp)) != EOF) {
/* your code */
}

}

My question is , since there is no ending mark up for binary file, why
does the code above work?

It ends when it reaches the physical end of the file.

also, why does built-in function feof(fp) know where is end-of-file?

feof() returns true when getc() has returned EOF, not before.

 

[Richard Bos]

I know that text file ended with EOF mark but there is no mark for
binary file.
So, the problem is how do we know the end of binary file is reach?

We don't have to; the implementation has to tell us (by returning EOF
instead of a value byte, e.g.), and it typically gets that information
from the underlying operating system.

My question is , since there is no ending mark up for binary file,

Well, there is. It just isn't inside the binary file data itself.
Usually it's a length field in the directory structure, or a block count
in the disk allocation tables, or something external like that.

also, why does built-in function feof(fp) know where is end-of-file?

It doesn't know that itself. All feof() does is signal that the last
function used to read from a stream signalled end of file; and those,
again, get that information from the OS, which gets it from the
directory structure or something similar.

Richard

 

[Richard Heathfield]

chat said:

Hi,
I know that text file ended with EOF mark but there is no mark for
binary file.

On some systems that is true, but the EOF mark you're talking about bears no
relation to C's EOF indicator, which is *not* a character stored on the
file system, but a special return value provided by getc (and one or two
other functions) to mean "sorry pal, nothing left to read". This works just
as well on binary files as on text files, and it works just as well on file
systems that do *not* store a byte meaning "end of file" at the end of text
files or indeed binary files.

 

[Keith Thompson]

How a text /file/ ends isn't defined by the C standard. What /is/
defined is what happens when you try and read the postultimate
character of a FILE* [connected to a file] using (f)getc: you get
the magic value EOF. This is true whether or not you're reading
a "text file".

[However, this EOF may be preceeded by some number of 0's -- ISTR
it's zeroes -- not logically present in the file, because some
systems at some time did or still do not record the exact number
of bytes kept in a file: files may contain integral numbers of
/blocks/ of bytes.]

Only binary files may be padded with zero bytes. With a text file,
you'll read only the characters that were actually written to it (with
some possible translation for end-of-line markers et al).

 

[aegis]

Hi,
I know that text file ended with EOF mark but there is no mark for
binary file.
So, the problem is how do we know the end of binary file is reach?

This code can tell us when the end of file is reach

int ch;

FILE *fp;

fp = fopen("filename","rb");

if(fp != NULL) {
while((ch = getc(fp)) != EOF) {
/* your code */
}

}

My question is , since there is no ending mark up for binary file, why
does the code above work?
also, why does built-in function feof(fp) know where is end-of-file?
thank you for all discussions.
chat watchara

EOF is a condition. It is not something that exists in a file.

 

[chat]

Thank you all discussions. Binary file is complicated than I think. The
way we can know where is the end-of-file is to ask the OS. The OS must
responsible for this job.
thank you very much.
chat watchara

 

[santosh]

Thank you all discussions. Binary file is complicated than I think.

Not if you understand it's limitations.

The way we can know where is the end-of-file is to ask the OS.

Actually, in a standard C program, failure to read from a stream, (and
hence from a disk file), is reported by returning the value represented
by the macro EOF for some functions, (getc, fgetc, getchar, scanf
etc.), by returning the value NULL for some functions, (fgets, gets),
and by returning a value other than what is expected, (fread).

To know whether the failure was caused by the stream being at
end-of-file or by an I/O error, you'll have to use the functions feof()
and ferror() immediatly after the failure is reported. Note that feof()
and ferror() work only with the standard library's I/O functions. If
you call other non-standard functions like POSIX read() or an OS API,
then you cannot use feof() or ferror().

So, in summary, for binary files, though you can know the end of input
in standard C, you cannot know the actual bytes making up the file
without resorting to non-standard functions.

 

[J. J. Farrell]

Thank you all discussions. Binary file is complicated than I think.

I think you must be misunderstanding something. Binary files are simple
and straightforward.

The way we can know where is the end-of-file is to ask the OS.

That's one way to do it. In pure C the way to do it is read characters
until EOF is returned.

The OS must responsible for this job.

The OS is clearly responsible for knowing how big the file is. The C
library works with the OS to make sure that you will get EOF after you
read the last character of the file.

 

[Chris Dollin]

How a text /file/ ends isn't defined by the C standard. What /is/
defined is what happens when you try and read the postultimate
character of a FILE* [connected to a file] using (f)getc: you get
the magic value EOF. This is true whether or not you're reading
a "text file".

[However, this EOF may be preceeded by some number of 0's -- ISTR
it's zeroes -- not logically present in the file, because some
systems at some time did or still do not record the exact number
of bytes kept in a file: files may contain integral numbers of
/blocks/ of bytes.]

Only binary files may be padded with zero bytes.

I /said/ that -- wait, I didn't, I only thought I did. Oops.

Thanks for spotting that, Keith.