Re: getline vs linebuffer

2011/9/27 Pádraig Brady : > On 09/27/2011 11:12 PM, Reuben Thomas wrote: > Note when testing io functions ensure that gnulib/lib/unlocked-io.h > is used appropriately, especially for getc using functions like getndelim2() The point Eric was making is that getndelim2 doesn't use getc (if it can hel

Re: getline vs linebuffer

On 09/27/2011 11:12 PM, Reuben Thomas wrote: > On 27 September 2011 22:45, Reuben Thomas wrote: >> On 26 September 2011 23:24, Eric Blake wrote: >>> >>> So _both_ linebuffer and getdelim would benefit from a conversion to >>> freadptr. >> >> I just tried using getndelim2 instead of getline for a

Re: getline vs linebuffer

On 27 September 2011 22:45, Reuben Thomas wrote: > On 26 September 2011 23:24, Eric Blake wrote: >> >> So _both_ linebuffer and getdelim would benefit from a conversion to >> freadptr. > > I just tried using getndelim2 instead of getline for a program which > slurps text line by line but spends m

Re: getline vs linebuffer

On 26 September 2011 23:24, Eric Blake wrote: > > So _both_ linebuffer and getdelim would benefit from a conversion to > freadptr. I just tried using getndelim2 instead of getline for a program which slurps text line by line but spends most of its time regexp-searching the text, and it made no de

Re: getline vs linebuffer

On 09/26/2011 04:04 PM, Eric Blake wrote: On 09/26/2011 03:47 PM, Reuben Thomas wrote: Is linebuffer obsoleteable in the face of standardized getline and friends? Not necessarily, because linebuffer provides a slightly different interface that might be easier to use. However, I do argue that b

Re: getline vs linebuffer

On 26 September 2011 23:19, Eric Blake wrote: > But a patch for both modules that references the other may indeed be > worthwhile. Great, I'll write something (and I find your arguments convincing). At the moment the short descriptions in the module files are identical, which is confusing. The c

Re: getline vs linebuffer

On 09/26/2011 04:06 PM, Reuben Thomas wrote: On 26 September 2011 23:04, Eric Blake wrote: On 09/26/2011 03:47 PM, Reuben Thomas wrote: Is linebuffer obsoleteable in the face of standardized getline and friends? Not necessarily, because linebuffer provides a slightly different interface tha

Re: getline vs linebuffer

Hi Reuben, > Is linebuffer obsoleteable in the face of standardized getline and friends? I'm not the maintainer of either of these modules, but I don't consider 'linebuffer' to be obsolete. Whenever I have to understand the calling convention of getline(), I get dizzy. What will happen if linept

Re: getline vs linebuffer

On 26 September 2011 23:04, Eric Blake wrote: > On 09/26/2011 03:47 PM, Reuben Thomas wrote: >> >> Is linebuffer obsoleteable in the face of standardized getline and >> friends? > > Not necessarily, because linebuffer provides a slightly different interface > that might be easier to use. If other

Re: getline vs linebuffer

On 09/26/2011 03:47 PM, Reuben Thomas wrote: Is linebuffer obsoleteable in the face of standardized getline and friends? Not necessarily, because linebuffer provides a slightly different interface that might be easier to use. However, I do argue that both linebuffer and getdelim can be writt

new module 'calloc-posix' (was: Re: getline() behaviour change)

Eric Blake wrote: > > I would somewhat like this idea - it is much nicer assuming that malloc > > reliably sets errno to ENOMEM on failure than having to patch all callers > > of malloc to do the same. Jim Meyering confirmed: > Yes. This is a fundamental goal of gnulib: > If there is some portabi

Re: getline() behaviour change

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Ben Pfaff on 8/22/2007 5:19 PM: >> Bruno Haible <[EMAIL PROTECTED]> writes: >> >>> Jim Meyering wrote: A *lot* of code expects malloc and realloc to set errno when they fail. >>> Such code is not portable to plain ISO C 99 systems. >> >> We

Re: getline() behaviour change

Ben Pfaff <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> Jim Meyering wrote: >>> A *lot* of code expects malloc and realloc to set errno when they fail. >> >> Such code is not portable to plain ISO C 99 systems. > > We could extend gnulib's existing malloc/realloc wrapp

do not set errno after failing malloc [Re: getline() behaviour change

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Are you advocating support for non-POSIX malloc/realloc? > > Sure. gnulib supports - to a large extent - mingw. It uses a malloc > implementation from msvcrt.dll. This malloc does not set errno. You're dumbing down gnulib to accommod

Re: getline() behaviour change

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ben Pfaff on 8/22/2007 5:19 PM: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> Jim Meyering wrote: >>> A *lot* of code expects malloc and realloc to set errno when they fail. >> Such code is not portable to plain ISO C 99 systems. > > W

Re: getline() behaviour change

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/22/2007 3:25 PM: >> >> - if (*lineptr == NULL || *n == 0) >> + if (*n == 0) > > This is a behaviour change: Previously when *lineptr == NULL, *n did not > need to be initialized. Now it needs to be initialized to 0.

Re: getline() behaviour change

Bruno Haible <[EMAIL PROTECTED]> writes: > Jim Meyering wrote: >> A *lot* of code expects malloc and realloc to set errno when they fail. > > Such code is not portable to plain ISO C 99 systems. We could extend gnulib's existing malloc/realloc wrappers to ensure that malloc/realloc set errno when

Re: getline() behaviour change

Jim Meyering wrote: > Are you advocating support for non-POSIX malloc/realloc? Sure. gnulib supports - to a large extent - mingw. It uses a malloc implementation from msvcrt.dll. This malloc does not set errno. > A *lot* of code expects malloc and realloc to set errno when they fail. Such code i

Re: getline() behaviour change

Hi Bruno, Thanks for all the reviews. I haven't had time to look at the rest, but the following stood out: Bruno Haible <[EMAIL PROTECTED]> wrote: > The POSIX spec implies that errno should be set when getdelim fails. Therefore > errno needs to be set not only here, with EOVERFLOW. In lines 77 an

Re: getline() behaviour change

Hi Eric, > The patch includes a couple of bug fixes in getdelim.c: > > It is valid on entrance for *lineptr to be non-NULL but *n to be 0 (ie. > via malloc(0)), but your implementation was leaking that memory. Also, > your implementation failed to set errno to EOVERFLOW when it detects that > it

Re: getline: protect prototype better

Simon Josefsson wrote: > This was also discovered while porting GNU SASL to uClinux. > > Perhaps I should investigate how difficult it would be to make uClinux > run ./configure properly instead of maintaining the HAVE_* symbols > manually. Definitely. uClinux has a shell and a compilation environ

Re: getline: protect prototype better

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> This was also discovered while porting GNU SASL to uClinux. >> >> Perhaps I should investigate how difficult it would be to make uClinux >> run ./configure properly instead of maintaining the HAVE_* symbols >> manually. > > Defin

Re: getline: protect prototype better

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> How about this? If for some reason HAVE_DECL_GETLINE is not defined >> at all, the header file fail to parse. > > What's the point in trying to use lib/getline.c without m4/getline.m4 ? > We engage ourselves to maintain both in

Re: getline: protect prototype better

Simon Josefsson <[EMAIL PROTECTED]> wrote: > How about this? If for some reason HAVE_DECL_GETLINE is not defined > at all, the header file fail to parse. This uses the idiom that is > suggested by the autoconf manual. > > 2005-08-23 Simon Josefsson <[EMAIL PROTECTED]> > > * getline.h (get

Re: getline: protect prototype better

Simon Josefsson <[EMAIL PROTECTED]> writes: > How about this? If for some reason HAVE_DECL_GETLINE is not defined > at all, the header file fail to parse. This uses the idiom that is > suggested by the autoconf manual. > > 2005-08-23 Simon Josefsson <[EMAIL PROTECTED]> > > * getline.h (g

Re: getline

Paul Eggert <[EMAIL PROTECTED]> writes: > That patch (in > ) > looks reasonable to me, though I haven't had time to test it myself. > Please install it, and we can deal with any porting problems later. I installed the patch. Tha

Re: getline

That patch (in ) looks reasonable to me, though I haven't had time to test it myself. Please install it, and we can deal with any porting problems later. ___ bug-gnulib mailing list bug

Re: getline

Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> 5. I have no idea whether using flockfile/funlockfile is appropriate. > > I'd say it's appropriate, but only if flockfile/funlockfile exist. > They don't exist on all platforms. POSIX says they're optional;

Re: getline

Simon Josefsson <[EMAIL PROTECTED]> writes: > 5. I have no idea whether using flockfile/funlockfile is appropriate. I'd say it's appropriate, but only if flockfile/funlockfile exist. They don't exist on all platforms. POSIX says they're optional; they're part of the Thread Safe Functions extensi

Re: getline

5. I have no idea whether using flockfile/funlockfile is appropriate. The glibc code invoked some locking macros, which I translated into flockfile/funlockfile. getndelim2 does not appear to do any locking, though. Reading the man page for flockfile, using them didn't seem like an obv

Re: getline

This is a rough start, to let you see my thinking. If this is OK, I'll write ChangeLog entries for it. The getdelim in glibc appear to suffer from a missing overflow check in the realloc call, but I may be mistaken. I fixed that while porting the code below. 1. There are separate modules for ge

Re: getline

Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> 1) Port the libc LGPL getdelim into a gnulib module. >> 2a) Port the libc LGPL getline into a gnulib module. >> 2b) Write a gnulib LGPL getline module that use the gnulib LGPL getdelim. >> 3) Keep the curren

Re: getline

Simon Josefsson <[EMAIL PROTECTED]> writes: > 1) Port the libc LGPL getdelim into a gnulib module. > 2a) Port the libc LGPL getline into a gnulib module. > 2b) Write a gnulib LGPL getline module that use the gnulib LGPL getdelim. > 3) Keep the current getndelim2 as a GPL module. > > The libc getli

Re: getline

I'm following up on this thread, it may be useful (or not..) to rehash it: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/2710 As you can see, I gave up and ported the glibc implementation into a gnulib module and used that. I read the libc getline and getdelim implementations now, and they