Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Buffer contents well-defined after fgets() reaches EOF ?
Date: Sat, 15 Feb 2025 08:12:33 -0800
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <86cyfjyyoe.fsf@linuxsc.com>
References: <vo9g74$fu8u$1@dont-email.me> <vo9hlo$g0to$1@dont-email.me> <vo9khf$ggd4$1@dont-email.me> <vobf3h$sefh$2@dont-email.me> <vobjdt$t5ka$1@dont-email.me> <vobkd5$t7np$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 15 Feb 2025 17:12:34 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c7695d44d5813647a552660a568166b3";
	logging-data="109065"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/TOhs6K4fBQ0YgW5w/cH+qQ5gFzRzyrx0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:47pLIokxeQomi7QbM5LvHrxcgKw=
	sha1:Ld2I08DwDLppkaL86TjYv0sAFP4=
Bytes: 2283

Andrey Tarasevich <noone@noone.net> writes:

> On Sun 2/9/2025 5:06 PM, Andrey Tarasevich wrote:
>
>> On Sun 2/9/2025 3:52 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Sat, 8 Feb 2025 23:12:44 -0800, Andrey Tarasevich wrote:
>>>
>>>> If `fgets` reads nothing (instant end-of-file), the entire
>>>> buffer remains untouched.
>>>
>>> You mean, only a single null byte gets written.
>>
>> No.  The buffer is not changed at all in such case.
>
> ... which actually raises an interesting quiz/puzzle/question:
>
>   Under what circumstances `fgets` is expected to return an empty
> string?  (I.e. set the [0] entry of the buffer to '\0' and return
> non-null)?
>
> The only answer I can see right away is:
>
>   When one calls it as `fgets(buffer, 1, file)`, i.e. asks it to
> read 0 characters.
>
> This is under assumption that asking `fgets` to read 0 characters
> is supposed to prevent it from detecting end-of-file condition or
> I/O error condition.  One can probably do some nitpicking at the
> current wording... but I believe the above is the intent.

Clearly there are more than a few C implementors who agree with that.