Re: [OT] Help with glibc memory streams
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> ---
Reply to: