From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) by sourceware.org (Postfix) with ESMTPS id C76F7388E834 for ; Tue, 11 May 2021 14:11:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C76F7388E834 Received: by mail-il1-x12f.google.com with SMTP id p15so17286635iln.3 for ; Tue, 11 May 2021 07:11:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xd4dfQp+oW9Wq98GD6lVOyhk75UjoQ99RZcBtU19VpE=; b=NDZ564syQSCeYaFcEzFhALDaOEU+sJ0FD05SeBPWwNOMx02J2Nf/KDr270cYA6N91h MtiujYORWmTiS/9I0PBR3Hzj4PrFXH5Pv4KIan0olOreU82/6RslqVpstK/Ez192wuXa PkR7zSBubJyzuXCU9I2ySguSKbeAXTynX5MF+Jm3TW57jsEKC7EG2Ra3WU2nbYhHsvfy gOpbKOhmiHM2VQRSyfhJzxeut9wmMydTPY6XRgs0aqRjwR3CkkbVstrtjGDr2AwcJxqQ g+s9kBB3n1Cf1D774MJ3X1ASsisE48MMnYhTWn+OrxYT1ka3ynvK2JoSZVEOVkJe+5aS +xig== X-Gm-Message-State: AOAM5312n5Fhb2g+XQ345gfhU5a83/5g2ZC/4osNZfAaBtv7ixV0UfvY JM4CkEnIGiuF9qcluSSNPO3+C66VFaeI2JujpzU= X-Google-Smtp-Source: ABdhPJxdQNQCrHzPLvb0CFKtJPKkCZP282JT2ych3C98gxF88JOj0viw+0BNLLSQYuPo6IZGb9spVDQsI9QZvmSZQbo= X-Received: by 2002:a05:6e02:1baf:: with SMTP id n15mr26696368ili.148.1620742261316; Tue, 11 May 2021 07:11:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5e:d714:0:0:0:0:0 with HTTP; Tue, 11 May 2021 07:11:00 -0700 (PDT) In-Reply-To: <441ba9e9ac3b9ed851b10d39025f905eef21cdea.camel@yandex.ru> References: <441ba9e9ac3b9ed851b10d39025f905eef21cdea.camel@yandex.ru> From: Peng Yu Date: Tue, 11 May 2021 09:11:00 -0500 Message-ID: Subject: Re: EOF is a misnomer? To: Konstantin Kharlamov Cc: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 14:11:07 -0000 On 5/11/21, Konstantin Kharlamov 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