public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Peng Yu <pengyu.ut@gmail.com>
To: Konstantin Kharlamov <hi-angel@yandex.ru>
Cc: libc-help@sourceware.org
Subject: Re: EOF is a misnomer?
Date: Tue, 11 May 2021 09:11:00 -0500	[thread overview]
Message-ID: <CABrM6wngoR5iZr3cEG9f+EAyJTaqrFLdh6vbCfQqazoDGmeK+A@mail.gmail.com> (raw)
In-Reply-To: <441ba9e9ac3b9ed851b10d39025f905eef21cdea.camel@yandex.ru>

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

  reply	other threads:[~2021-05-11 14:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11 13:27 Peng Yu
2021-05-11 13:38 ` Konstantin Kharlamov
2021-05-11 14:11   ` Peng Yu [this message]
2021-05-11 13:42 ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABrM6wngoR5iZr3cEG9f+EAyJTaqrFLdh6vbCfQqazoDGmeK+A@mail.gmail.com \
    --to=pengyu.ut@gmail.com \
    --cc=hi-angel@yandex.ru \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).