Re: [OT] Help with glibc memory streams

[Enrique Robledo Arnuncio <era@ieeesb.etsit.upm.es>]

On Sun, Oct 29, 2000 at 10:36:47PM +0200, Eray Ozkural (exa) wrote:
> > This is, IMO, a legitimate bug. Note, I also tested this same problem with
> > fgetc() and it worked perfectly, so this is a problem in fgets.
> 
> Thanks a lot. I presume you'll be discussing this problem in bug-glibc
> as you're libc6's maintainer, or would you like me to draw their attention
> to this problem?

It seems to be fgets fault, but is it a bug really?

from the info manual (fgets),

     The `fgets' function reads characters from the stream STREAM up to
     and including a newline character and stores them in the string S,
     adding a null character to mark the end of the string.  
     [...]
     If the system is already at end of file when you call `fgets', then
     the contents of the array S are unchanged and a null pointer is
     returned.  A null pointer is also returned if a read error occurs.
     Otherwise, the return value is the pointer S.

So, it does not say what happens if fgets find an end of file before
finding the newline character.

Also, from K&R,

    fgets reads at most the next n-1 characters into the array s,
    stopping if a newline is encountered; the newline is included in
    the array, which is terminated by '\0'. fgets returns s, or NULL
    if end of file or error occurs.

So neither of them say what happens fgets finds an EOF "in the middle" of
a line. K&R seems to mean it would be an error.

I guess that's why text files not ending with an end of line are
sometimes problematic.... Maybe you should follow the info advice, and
try getline instead.

--- Enrique Robledo Arnuncio <erobledo@ieee.org>
                             <erobledo@die.upm.es>
                             <era@ieeesb.etsit.upm.es> ---