Re: fgets/strtok and LINE_MAX

[shwaresyst@xxxxxxx]

Could be less a bug in the example than the wording of the function's 
behavior. Taking the function description literally, you do have a case 
that there's a discrepancy. Taking the example as an expression of the 
intent of the description, though, it could be interpreted that up to 
n-1 characters will be read that aren't newline chars by an 
implementation and if it gets that far the nth char is to be assumed to 
be a newline, as the function is intended for use with well formed text 
streams that would have honored the LINE_MAX length when created. As 
the stream can be any type of file, though, this assumption can't be 
guaranteed and the description is erroneously silent on whether the nth 
char explicitly should or shouldn't be validated as being that newline, 
and copied to the buffer if so, or is it a malformed line and that nth 
char should also be copied but with just the trailing null, or should a 
newline char be explicitly appended as char n and then the null, with 
the actual nth char left as the next char to be read or is it thrown 
away.

 In the case where char n is validated as a newline, an array with 
indexes 0..LINE_MAX will hold the entire well formed line and the 
trailing null char, so the function should exit successfully and the 
example is proper, but in the case of a malformed line the presence of 
just the terminating null character could be confused with an 
end-of-file condition where the stream did not end with a newline. As 
written, the end-of-file is only supposed to raise an error when an 
attempt is made to read from the stream past the end, not up to the 
end. The description also does not specify the behavior when nulls are 
read from the file. Copying these could lead an application to believe 
that end-of-file was reached also if the preceding character is 
anything other than a newline.

As such, the scope of the fgets() description appears to be deficient. 
I'm open to suggestion on whether an aardvark report or interpretation 
request is most suitable to address these, or should this be reported 
to the C working group since the description defers to the C standard.

Cheers,
Mark


-----Original Message-----
From: Vincent Lefevre <vincent-opgr@vinc17.org>
To: austin-group-l@xxxxxx
Sent: Mon, Nov 2, 2009 9:54 pm
Subject: Re: fgets/strtok and LINE_MAX










Hi,

I haven't seen any reply. Is this a bug or what?
In the LINE_MAX definition or in the example?

Note that the LINE_MAX definition says:

 Unless otherwise noted, the maximum length, in bytes, of the input
 line of a utility (either standard input or another file), when the
 utility is described as processing text files. The length includes
 room for the trailing <newline>.

i.e. it includes the trailing <newline>.

On 2009-09-21 01:03:13 +0200, Vincent Lefevre wrote:
> http://www.opengroup.org/onlinepubs/9699919799/functions/fgets.html
> says in the EXAMPLES section (page 852 in the PDF version):
>
>   The following example uses fgets() to read each line of input.
>   {LINE_MAX}, which defines the maximum size of the input line,
>   is defined in the <limits.h> header.
>
>   #include <stdio.h>
>   ...
>   char line[LINE_MAX];
>   ...
>   while (fgets(line, LINE_MAX, fp) != NULL) {
>   ...
>   }
>   ...
>
> However for a line of length LINE_MAX, LINE_MAX-1 bytes will be read,
> i.e. the last byte (here, the newline character) won't be read! This
> is wrong, isn't it?
>
> To be correct, the example should have LINE_MAX+1 instead of LINE_MAX
> (both occurrences). It would also assume that LINE_MAX < INT_MAX.
>
> Similarly, the strtok example (page 2041) looks wrong too.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)