EOF is a misnomer?

EOF is a misnomer?

[Peng Yu]

man getchar says

"       fgetc(), getc(), and getchar() return the character read as an unsigned
       char cast to an int or EOF on end of file or error."

EOF literally stands for end of file. But the above functions can
return EOF when there is an error.

In feof(), "eof" just means end of file as shown in man feof.

       The function feof() tests the  end-of-file  indicator  for  the  stream
       pointed  to by stream, returning nonzero if it is set.  The end-of-file
       indicator can be cleared only by the function clearer().

So the macro name EOF is a misnomer. It could have been named as
something like EOF_OR_ERR? The fact that its name is EOF is due to
some historical reasons? Thanks.

-- 
Regards,
Peng

Re: EOF is a misnomer?

[Konstantin Kharlamov]

On Tue, 2021-05-11 at 08:27 -0500, Peng Yu via Libc-help wrote:
> man getchar says
> 
> "       fgetc(), getc(), and getchar() return the character read as an unsigned
>        char cast to an int or EOF on end of file or error."
> 
> EOF literally stands for end of file. But the above functions can
> return EOF when there is an error.
> 
> In feof(), "eof" just means end of file as shown in man feof.
> 
>        The function feof() tests the  end-of-file  indicator  for  the  stream
>        pointed  to by stream, returning nonzero if it is set.  The end-of-file
>        indicator can be cleared only by the function clearer().
> 
> So the macro name EOF is a misnomer. It could have been named as
> something like EOF_OR_ERR? The fact that its name is EOF is due to
> some historical reasons? Thanks.
> 

You are probably right, but I don't think it is correct to ask that question to libc developers, whether it is Glibc or any other libc. The functions in question are part of C standard: https://en.cppreference.com/w/c/io/fgetc So any change in that regard would have to go through the procedure of sending a C language proposal to C committee.

That said, making any change to C language is very hard, see this article https://thephd.github.io/your-c-compiler-and-standard-library-will-not-help-you from a member of C committee. These days though I doubt there's much point in making changes to C, because we have Rust instead, which slowly makes its way even to the Linux kernel.

Re: EOF is a misnomer?

[Florian Weimer]

* Peng Yu via Libc-help:

> man getchar says
>
> "       fgetc(), getc(), and getchar() return the character read as an unsigned
>        char cast to an int or EOF on end of file or error."
>
> EOF literally stands for end of file. But the above functions can
> return EOF when there is an error.
>
> In feof(), "eof" just means end of file as shown in man feof.
>
>        The function feof() tests the  end-of-file  indicator  for  the  stream
>        pointed  to by stream, returning nonzero if it is set.  The end-of-file
>        indicator can be cleared only by the function clearer().
>
> So the macro name EOF is a misnomer. It could have been named as
> something like EOF_OR_ERR? The fact that its name is EOF is due to
> some historical reasons? Thanks.

It's this way for historical reasons.  EOF can also be a valid character
(if sizeof (int) is 1, as permitted by the C standard), so the whole
interface is a bit questionable.

Thanks,
Florian

Re: EOF is a misnomer?

[Peng Yu]

On 5/11/21, Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
> On Tue, 2021-05-11 at 08:27 -0500, Peng Yu via Libc-help wrote:
>> man getchar says
>>
>> "       fgetc(), getc(), and getchar() return the character read as an
>> unsigned
>>        char cast to an int or EOF on end of file or error."
>>
>> EOF literally stands for end of file. But the above functions can
>> return EOF when there is an error.
>>
>> In feof(), "eof" just means end of file as shown in man feof.
>>
>>        The function feof() tests the  end-of-file  indicator  for  the
>> stream
>>        pointed  to by stream, returning nonzero if it is set.  The
>> end-of-file
>>        indicator can be cleared only by the function clearer().
>>
>> So the macro name EOF is a misnomer. It could have been named as
>> something like EOF_OR_ERR? The fact that its name is EOF is due to
>> some historical reasons? Thanks.
>>
>
> You are probably right, but I don't think it is correct to ask that question
> to libc developers, whether it is Glibc or any other libc. The functions in
> question are part of C standard: https://en.cppreference.com/w/c/io/fgetc So
> any change in that regard would have to go through the procedure of sending
> a C language proposal to C committee.
>
> That said, making any change to C language is very hard, see this article
> https://thephd.github.io/your-c-compiler-and-standard-library-will-not-help-you
> from a member of C committee. These days though I doubt there's much point
> in making changes to C,

I agree with the above conclusion.

> because we have Rust instead, which slowly makes its
> way even to the Linux kernel.

But I don't think the above is the reason.

C can be viewed as a high-level assembly language. Anything written in
C can be more or less mapped to assembly code. An example is the
switch statement which can be mapped to the assembly code with
O(log(n)) time complexity, sometimes O(1) time complexity. It is quite
easy to evaluate what it does on the machine.

http://lazarenko.me/switch/

Note that the same assembly code can be done with even lower
representation in the code shown below the text "One of the possible
ways of doing this is to label our code and create an array that store
labels instead of functions."

As another example, one can do loop unrolling manually in C code. This
is also close to the assembly level.

https://en.wikipedia.org/wiki/Duff%27s_device

I don't think Rust is a replacement of C.

https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html

The real reason probably is that there is a large amount of existing
work based on C. It is just too late to change any bad names in C
standard.

-- 
Regards,
Peng