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

On 2/14/25 14:23, Janis Papanagnou wrote:
...

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.

As with several of the string processing functions, I think fgets()
would be better if it returned a pointer to the end of the data that was
read in, rather than to the beginning. The chaining you talk about does
not, in general, work properly if the return value from fgets() is NULL,
or the entire buffer was filled without writing a null character.