Re: getdelim doesn't set errno on failure?
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 platform which was prevoiusly looping indefinitely around code that expected (and has expected for years) a -1 return to signify EOF. 2005-08-31 Derek Price [EMAIL PROTECTED] * getdelim.c (getdelim): Return EOF on EOF. Reported by Larry Jones [EMAIL PROTECTED]. Look fine, applied! ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: getdelim doesn't set errno on failure?
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 first character is read. If it occurs after some non-empty string is already read, this non-empty string is returned. -1, errno!=0 (malloc failed, assuming malloc set errno) -1, errno!=0 (realloc failed, assuming realloc set errno) You cannot assume that malloc() and realloc() set errno upon failure. - In ISO C 99, the description of malloc() and realloc() does not mention errno. Also, errno.h is not required to declare a macro 'ENOMEM'. - Windows (mingw) malloc() and realloc() don't always set errno. But on the other hand, malloc() and realloc() are free to modify errno even when they succeed. (This happens e.g. on GNU/kFreeBSD, a glibc system.) Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: getdelim doesn't set errno on failure?
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 implementation of a function like malloc we can easily ensure that it is replaced. 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 set errno. What value do you expect in errno after malloc() failed? ENOMEM is the most frequent and maybe also the only reasonable choice when malloc() fails. What's the purpose then of setting errno then? ISO C 99 is not a substandard, and Windows malloc() is not poor just because it does not set errno. Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: getdelim doesn't set errno on failure?
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 set errno. What value do you expect in errno after malloc() failed? ENOMEM is the most frequent and maybe also the only reasonable choice when malloc() fails. What's the purpose then of setting errno then? ISO C 99 is not a substandard, and Windows malloc() is not poor just because it does not set errno. Gnulib already has a replacement malloc that handles malloc(0). Why not extend that to set errno on failure as well? Also, if we are to emulate a standard for broken systems, why not emulate POSIX? Regards, Oskar ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: getdelim doesn't set errno on failure?
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 interface design. If some system has a poor implementation of a function like malloc we can easily ensure that it is replaced. 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'. What value do you expect in errno after malloc() failed? ENOMEM is the most frequent and maybe also the only reasonable choice when malloc() fails. What's the purpose then of setting errno then? One of the goals of Gnulib is to hide portability vagaries like this. If being able to assume that malloc sets errno to ENOMEM upon failure can lead to a more useful implementation of getline, or to more reliable diagnostics in general, then I think it is fine to make getline depend on a slightly more-expensive, wrapped malloc -- on non-conforming systems. This is sort of like whether to code for conforming malloc/realloc/free when they are passed a size of 0 or a NULL pointer. Code that assumes the more useful (usually newer) standard -- relying on the wrapper when necessary -- is slightly cleaner and more maintainable, but with some small amount of overhead on systems that require the wrapper. That said, I don't particularly care how getline is implemented, as long as it can be used robustly and reasonably easily. ISO C 99 is not a substandard, As applied to a *system* that implements malloc that way, `substandard' seems like an apt description. Such a system falls short of a prescribed norm: relatively-recent POSIX. and Windows malloc() is not poor just because it does not set errno. Call it what you like, but lack of support for such a basic bit of functionality is certainly not a plus. My point is that Gnulib development should not be held hostage to a system that is behind the standards curve. If the workarounds (e.g., wrappers) required to keep the mainstream code clean end up being too expensive on Windows, we can hope that someone will profile things there and find a clean workaround. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
getdelim doesn't set errno on failure?
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 cur_len) is to
test for overflow.
Oskar Liljeblad ([EMAIL PROTECTED])
Index: getdelim.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/getdelim.c,v
retrieving revision 1.1
diff -u -p -r1.1 getdelim.c
--- getdelim.c 2 Aug 2005 09:33:30 - 1.1
+++ getdelim.c 23 Aug 2005 14:38:56 -
@@ -28,6 +28,11 @@
#include getdelim.h
+/* Some systems, like OSF/1 4.0 and Woe32, don't have EOVERFLOW. */
+#ifndef EOVERFLOW
+# define EOVERFLOW E2BIG
+#endif
+
#if !HAVE_FLOCKFILE
# undef flockfile
# define flockfile(x) ((void) 0)
@@ -86,6 +91,7 @@ getdelim (char **lineptr, size_t *n, int
if (needed cur_len)
{
+ errno = EOVERFLOW;
result = -1;
goto unlock_return;
}
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: getdelim doesn't set errno on failure?
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 cur_len) is to test for overflow. Right. How about using ENOMEM instead? Yes, that would be useful. It is hard as it is to handle errors from getline. Also the documentation from GNU libc seems wrong: If an error occurs or end of file is reached without any bytes read, `getline' returns `-1'. Here's what getdelim in Gnulib returns: -1, errno=EINVAL(an argument is NULL) -1, errno!=0(malloc failed, assuming malloc set errno) =0, errno undefined, feof (getc returned EOF, reached end of file) =0, errno!=0, ferror (getc returned EOF, read failed) -1, errno undefined (arithmetic overflow) -1, errno!=0(realloc failed, assuming realloc set errno) So getline/getdelim only returns -1 on invalid arguments or an out of memory condition, never on I/O errors or EOF! Or did I miss something? Regards, Oskar Liljeblad ([EMAIL PROTECTED]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
