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

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. It is not horrendous, like gets(), so I
personally would not suggest deprecation. Instead, I would suggest
addition of another function with similar goals, but better-thought API
to the Standard library.