EOF (novice)

[Kelli Halliburton]

[snip] Commodore's AmigaOS.

It was called Workbench at the time. It only became AmigaOS in its
'recent' (has it been five years already?) resurrection (see
http://os.amiga.com/).

It was called two things: Kickstart and Workbench. Kickstart provided the
core functionality, and Workbench provided the user-level interface.
Kickstart was the ROM (or in early systems, disk-loaded write-protected
RAM), and Workbench was loaded into ordinary RAM from disk, with Workbench
also being the name of the file management and program loader GUI. It's a
bit like separating early versions of MacOS into Toolbox, System, and
Finder.

 

[Paure]

--
Alan C this post ends with w
q

From K&R:

#include <stdio.h>

main()

/* copy input to output */

{

int c;

c = getchar();
while (c != EOF) {

putchar(c);
c = getchar();

}

}


If I am reading the text correctly, this program should
terminate when I enter -1 (EOF as defined on my system,
Linux).

But it doesn't. Just keeps right on trucking.

What gives?

AC

I think we should think about author's backdrop.In 1972,The first
edition of <<c programming language>>,The authors both used UNIX,and
In UNIX the input through FILE,so ...It is no worth in talking about
this,it is just a single of 'input end'.

 

[Joe Wright]

I think we should think about author's backdrop.In 1972,The first
edition of <<c programming language>>,The authors both used UNIX,and
In UNIX the input through FILE,so ...It is no worth in talking about
this,it is just a single of 'input end'.

An interesting view but not true. In 1972 Ken Thompson and Dennis
Ritchie were working very closely together and Thompson's final Unix was
essentially written in Ritchie's C. But there is a big difference
between an operating system and an implementation of a programming
language in a hosted environment. The FILE construct belongs to C, not
Unix. Likewise, EOF is a C thing, not a Unix one.

 

[James Hu]

An interesting view but not true. In 1972 Ken Thompson and Dennis
Ritchie were working very closely together and Thompson's final Unix was
essentially written in Ritchie's C. But there is a big difference
between an operating system and an implementation of a programming
language in a hosted environment. The FILE construct belongs to C, not
Unix. Likewise, EOF is a C thing, not a Unix one.

Why is EOF a C thing? The concept of "end of file" predates C. The
identifier "EOF" existed in other languages prior to C.

-- James

 

[Hallvard B Furuseth]

Why is EOF a C thing? The concept of "end of file" predates C. The
identifier "EOF" existed in other languages prior to C.

What we mean by EOF when we talk C, is C's EOF constant, which is a C
thing. It is a constant #defined by stdio.h which is returned by
getchar() & co instead of a character when the end of the file is
reached. This EOF constant is not present in the physical file, which
represents the end of the file in some other way. (Maybe a byte count
in the file description says where the file ends, for example.)

 

[Joe Wright]

Why is EOF a C thing? The concept of "end of file" predates C. The
identifier "EOF" existed in other languages prior to C.

The point was that EOF (in context of the OP) is a C thing rather than a
Unix thing. I have no idea in how many languages EOF may be an
identifier. And neither do you.

 

[James Hu]

What we mean by EOF when we talk C, is C's EOF constant, which is a C
thing. It is a constant #defined by stdio.h which is returned by
getchar() & co instead of a character when the end of the file is
reached.

I know EOF is an out of band indicator. I am contending that the
concept is not a C concept. Please review this very long thread.

This EOF constant is not present in the physical file, which
represents the end of the file in some other way. (Maybe a byte count
in the file description says where the file ends, for example.)

The byte pattern that matches the EOF integer value may very well be
the marker that delimits the end of the file on the physical storage.
(We don't know how it is done, nor should we care.)

Regards,

-- James

 

[James Hu]

The point was that EOF (in context of the OP) is a C thing rather than a
Unix thing.

Please review the thread. The OP complained that K&R did not explain
how to end the input to the "simple cat" C program. How this is done
is peculiar to the platform of the compiler, not a construct of the
programming language.

I have no idea in how many languages EOF may be an identifier. And
neither do you.

I never contended to know how many.

Regards,

-- James

 

[Joe Wright]

I know EOF is an out of band indicator. I am contending that the
concept is not a C concept. Please review this very long thread.


The byte pattern that matches the EOF integer value may very well be
the marker that delimits the end of the file on the physical storage.
(We don't know how it is done, nor should we care.)

You are missing something here James. EOF is a macro definition of
stdio.h and on most systems has a value of (-1). This has absolutely
nothing to do with patterns of markers written to physical storage.
Nothing. The operating system, for its own purposes, may well define
"end of file" somehow but this is not EOF. EOF is a C thing (in our
current context).

 

[James Hu]

You are missing something here James. EOF is a macro definition of
stdio.h and on most systems has a value of (-1). This has absolutely
nothing to do with patterns of markers written to physical storage.
Nothing. The operating system, for its own purposes, may well define
"end of file" somehow but this is not EOF. EOF is a C thing (in our
current context).

I am not sure you read my post carefully enough.

Regards,

-- James

 

[Hallvard B Furuseth]

The byte pattern that matches the EOF integer value may very well be
the marker that delimits the end of the file on the physical storage.

No. All byte patterns in the file are returned as a non-negative value
from getchar(). EOF is negative, precicely so that it cannot fit in
the file.

The exception is when int is one byte and INT_MAX < UCHAR_MAX. That's
very rare, and very few programs even care about the possibility.

 

[James Hu]

No. All byte patterns in the file are returned as a non-negative value
from getchar(). EOF is negative, precicely so that it cannot fit in
the file.

You had said:

This EOF constant is not present in the physical file ...

I am not saying that getchar() returns this byte constant as part of
its read. What I said was:

(We don't know how it is done, nor should we care.)

The word "it" refers to "EOF detection on the C compiler's platform."

It is not inconceivable for a system to buffer read a file and scan
the bytes for a sizeof(int) bytes long bit pattern before determining
whether it should return the next char as input or return EOF instead.
Of course, in such a scheme, the system would need to be able to escape
the bit pattern if it wanted to be able to scan the bytes literally.
(We don't know how it is done, nor should we care.)

Regards,

-- James

 

[Dan Pop]

No. All byte patterns in the file are returned as a non-negative value
from getchar(). EOF is negative, precicely so that it cannot fit in
the file.

The exception is when int is one byte and INT_MAX < UCHAR_MAX. That's
very rare, and very few programs even care about the possibility.

That's actually pathologic on a hosted implementation and the standard
implicitly (unfortunately) assumes that it can't happen. I have yet to
hear about such a hosted implementation in the real world.

Dan

 

[Ben Pfaff]

That's actually pathologic on a hosted implementation and the standard
implicitly (unfortunately) assumes that it can't happen. I have yet to
hear about such a hosted implementation in the real world.

Sounds like a chicken-and-egg problem. No one would dare put out
such an implementation, because so much software would break, but
no one bothers to write software resilient against it, because
there are no such hosted implementations.

 

[Dan Pop]

Sounds like a chicken-and-egg problem. No one would dare put out
such an implementation, because so much software would break, but
no one bothers to write software resilient against it, because
there are no such hosted implementations.

Therefore, it would cost nothing to explicitly forbid it in the standard.
Yet, the standard doesn't do it.

Dan

 

[Dan Pop]

It is not inconceivable for a system to buffer read a file and scan
the bytes for a sizeof(int) bytes long bit pattern before determining
whether it should return the next char as input or return EOF instead.
Of course, in such a scheme, the system would need to be able to escape
the bit pattern if it wanted to be able to scan the bytes literally.
(We don't know how it is done, nor should we care.)

I'm afraid I don't get it. Any byte combination can be used in a binary
file without meaning anything at all for the implementation. Only the
program reading the file can assign one meaning or another to a certain
combination of bytes. The standard makes it clear that an implementation
is not required to be able to locate the logical end of a binary file
(in which case, all the characters between the logical eof and the
physical eof are null).

For text files, a single eof character is enough to mark the end of the
text file, even if the physical file is larger (up to the end of the
logical disk block). This is the well known scheme used by CP/M-80.

Dan

 

[James Hu]

I'm afraid I don't get it. Any byte combination can be used in a binary
file without meaning anything at all for the implementation. Only the
program reading the file can assign one meaning or another to a certain
combination of bytes. The standard makes it clear that an implementation
is not required to be able to locate the logical end of a binary file
(in which case, all the characters between the logical eof and the
physical eof are null).

If the standard explicitly or implicitly makes a non requirement, then
the implementation is free to satisfy it or not ("we don't know how it
is done"). A strictly conforming C program cannot make any assumptions
about whether the non requirement is present or not ("nor should we
care").

If you want a practical example, consider a stdio interface implemented
over a compressed filesystem.

For text files, a single eof character is enough to mark the end of the
text file, even if the physical file is larger (up to the end of the
logical disk block). This is the well known scheme used by CP/M-80.

A single character is sufficient but not necessary. My multi-byte EOF
system is hypothetical.

-- James

 

[Hallvard B Furuseth]

A single character is sufficient but not necessary. My multi-byte EOF
system is hypothetical.

It doesn't matter. Your multi-byte EOF is still not C's EOF, it's just
a byte sequence which it happens to be possible to interpret as the same
value as the C implementation's EOF constant. If you keep the system
but replace that C implementation with another which #defines EOF as
some other constant, then the system's EOF byte sequence will remain the
same but it will no longer match that new C implementation's EOF
constant.

In short C's EOF is C's EOF and not the system's EOF, no matter what
tricks you play with the system's EOF. Assuming the system _has_ an
EOF sequence and not a file-size attribute or something.

 

[Dan Pop]

If the standard explicitly or implicitly makes a non requirement, then
the implementation is free to satisfy it or not ("we don't know how it
is done"). A strictly conforming C program cannot make any assumptions
about whether the non requirement is present or not ("nor should we
care").

If you want a practical example, consider a stdio interface implemented
over a compressed filesystem.

I still don't get it. Each and every byte combination is still valid
in a binary file, therefore it *cannot* be used as eof marker.

A single character is sufficient but not necessary. My multi-byte EOF
system is hypothetical.

That's true and irrelevant in the case of text files. My point is that
your scheme simply does not work for binary files. Furthermore, EOF
is a C macro having no connection with whatever mechanism the
implementation uses to detect the end of a file. All we know about it
is that it expands to a negative integer value.

Dan

 

[James Hu]

It doesn't matter.

Of course not. "We don't know nor should we care" clearly spells that
out. You claimed that EOF was *not* stored on the physical medium. My
point is that it may or may not be, but to the strictly conforming C
program, it doesn't matter.

Regards,

-- James