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

First; thanks Kaz and Andrey for the replies. - As so often answering
more than I asked or needed. :-)

The provided C standard quote answers my question. - Thanks!


On 09.02.2025 07:23, Andrey Tarasevich wrote:

On Sat 2/8/2025 9:59 PM, Janis Papanagnou wrote:

To get the last line of a text file I'm using
>
     char buf[BUFSIZ];
     while (fgets (buf, BUFSIZ, fd) != NULL)
         ;   // read to last line
>
If the end of the file is reached my test shows that the previous
contents of 'buf' are still existing (not cleared or overwritten).
>
But the man page does not say anything whether this is guaranteed;
it says: "Reading stops after an EOF or a newline.", but it says
nothing about [not] writing to or [not] resetting the buffer.
>
Is that simple construct safe to get the last line of a text file?
>

 
What situation exactly are you talking about? When end-of-file is
encountered _immediately_, before reading the very first character? Of
when end-of-file is encountered after reading something (i.e. when the
last line in the file does not end with new-line character)?

I have a _coherent_ file, with a few NL terminated lines of text.

Usually I use fgets() in contexts where I process every line, like

    while (fgets (buf, BUFSIZ, fd) != NULL) {
        operate_on (buf);
    }
    // here the status of buf[] is usually not important any more

My actual context was different, like

    while (fgets (buf, BUFSIZ, fd) != NULL) {
        // buf[] contents are ignored here
    }
    operate_on (buf[]);  // which I assumed contains last line

 
The former situation is covered by the spec: "If end-of-file is
encountered and no characters have been read into the array, the
contents of the array remain unchanged and a null pointer is returned".
 
The second situation does not need additional clarifications. Per
general spec as many characters as available before the end-of-file will
be read and then terminated with '\0'. In such case there will be no
new-line character in the buffer.
 
So, in both cases we are perfectly safe when reading the last line of a
text file, if you don't forget to check the return value of `fgets`.

I suppose you mean what I already had in my code above:  ... != NULL

 
(This is all under assumption that size limit does not kick in. I
believe your question is not about that.)

Yes, it was just the one posted question. (No incoherent text files,
no error conditions, no signals, no buffer size mistakes, etc.)

 
Note also that `fgets` is not permitted to assume that the limit value
(the second parameter) correctly describes the accessible size of the
buffer. E.g. for this reason it is not permitted to zero-out the buffer
before reading. For example, this code is valid and has defined behavior
 
  char buffer[10];
  fgets(buffer, 1000, f);
 
provided the current line of the file fits into `char[10]`. I.e. even
though we "lied" to `fgets` about the limit, it is still required to
work correctly if the actual data fits into the actual buffer.
 
So, why do you care that "the previous contents of 'buf' are still
existing"?

I hope it got clear by the two code snippets I posted above...

Usually I read and process the data that I got in buf from fgets()
while there *is* data (fgets() != NULL), and I thus don't care any
more about buffer contents validity after the loop (fgets() == NULL).

But now I wanted to ignore all data that I got for fgets() != NULL
in the loop. And I hoped that *after* the loop the last read data is
still valid.

Janis