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

On 14.02.2025 15:51, Michael S wrote:

[ fgets() poorly defined? ] 

 
[...]

Just a comment on this:

Then, everything about it feels inelegant.
A return value carries just 1 bit of information, success or failure.
So why did they encode this information in baroque way instead of
something obvious, 0 and 1?

I consider it to be differently; it basically returns a pointer
to work with on the data, and the special NULL pointer value is
just the often seen hack where a special pointer value provides
an error indication.

Typical application (for me) is

    if ((line = fgets (buf, BUFSIZ, fd)) == NULL)
        // handle error...
    else
        // process data

Moreover, returning the pointer to the data makes it possible to
(e.g.) nest string processing functions (including 'fgets') or
to chain processing or immediate access/dereference the string
contents.

IMO the 'fgets' function matches the typical interface for such
string functions (in C) allowing such programming language idioms
like the two or three mentioned.

I think it is generally arguable whether code patterns like
    if ((line = fgets (buf, BUFSIZ, fd)) == NULL)
can be considered clean code with clean syntax and a clean design.
But not in a "C" language newsgroup where such things are typical
(with this function design) as language specific code pattern.

Janis

[...]