Re: Buffer contents well-defined after fgets() reaches EOF ?

Michael S <already5chosen@yahoo.com> writes:

On Sun, 9 Feb 2025 17:22:43 -0800
Andrey Tarasevich <noone@noone.net> wrote:
>

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.

>
fgets() is one of many poorly defined standard library functions
inherited from early UNIX days.  [...]

What about the fgets() function do you think is poorly defined?

Second question: by "poorly defined" do you mean "defined
wrongly" or "defined ambiguously" (or both)?