Derek Price [EMAIL PROTECTED] writes:
Whoa! Why fix the documentation? Why not simply return EOF on EOF, as
currently described? The attached simple patch fixes this in
lib/getdelim.c, matching the behavior to that displayed by my local
glibc. This fix has been tested on at least one
Oskar Liljeblad wrote:
Here's what getdelim in Gnulib returns:
=0, errno undefined, feof (getc returned EOF, reached end of file)
=0, errno!=0, ferror (getc returned EOF, read failed)
Actually I think the glibc doc means that -1 is returned if EOF or read
failure occurs before the
Jim Meyering wrote:
Note that POSIX *does* require a failed malloc call to set errno to
ENOMEM, albeit with CX shading (meaning IEEE Std 1003.1-2001).
http://www.opengroup.org/susv3xsh/malloc.html
Let's try not to let substandard systems dictate interface design.
If some system has a poor
On Wednesday, August 24, 2005 at 15:52, Bruno Haible wrote:
I'm not in favour of a wrapper around malloc(), that would add overhead to
a function called as frequently as malloc(), just to set 'errno'.
ISO C 99 is not a substandard, and Windows malloc() is not poor just
because it does not
Bruno Haible [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
Note that POSIX *does* require a failed malloc call to set errno to
ENOMEM, albeit with CX shading (meaning IEEE Std 1003.1-2001).
http://www.opengroup.org/susv3xsh/malloc.html
Let's try not to let substandard systems dictate
On Tuesday, August 23, 2005 at 17:59, Jim Meyering wrote:
Oskar Liljeblad [EMAIL PROTECTED] wrote:
I don't know if this is necessary or necessarily correct, but
it seems getdelim doesn't always set errno on failure (when it
returns -1).
From what I can tell, the test below (needed
