On 26 September 2011 23:24, Eric Blake ebl...@redhat.com 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
On 27 September 2011 22:45, Reuben Thomas r...@sc3d.org wrote:
On 26 September 2011 23:24, Eric Blake ebl...@redhat.com 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
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 detectable difference, so I guess it really
does have to be hardcore slurping.
Or perhaps glibc's getline is efficient?
I found it very efficient
http
2011/9/27 Pádraig Brady p...@draigbrady.com:
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
Is linebuffer obsoleteable in the face of standardized getline and friends?
--
http://rrt.sc3d.org
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
On 26 September 2011 23:04, Eric Blake ebl...@redhat.com 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
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
On 09/26/2011 04:06 PM, Reuben Thomas wrote:
On 26 September 2011 23:04, Eric Blakeebl...@redhat.com 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
is confusing.
The consensus seems to be that linebuffer is easier to use and
possibly more flexible.
(BTW, getline *is* a GNU interface, just one that happened to be
standardized, at least, according to the man page.)
--
http://rrt.sc3d.org
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
The log says this:
checking whether getline is declared... no
checking for getline... yes
I'm updating the doc:
2010-07-30 Bruno Haible br...@clisp.org
getline: Update regarding AIX.
* doc/posix-functions/getline.texi: Mention bug on AIX 7.1.
Reported by Rainer
A different case is this error:
../gllib/stdio.h:803: error: `getline' was not declared in this scope
Here we really want to do #define getline rpl_getline even if the system
does not declare the function, for the reason mentioned in the documentation:
Some platforms provide a function
Eric Blake wrote:
FreeBSD is buggy. Rewording the POSIX requirement slightly: if lineptr is
NULL, then it is irrelevant that linecapp is non-zero.
I agree.
Gnulib needs to work around this portability flaw, and guarantee a working
getline implementation even on fBSD, at which point, your
2010-01-31 Bruno Haible br...@clisp.org
Work around getline() bug on FreeBSD 8.0.
* m4/getline.m4 (gl_FUNC_GETLINE): Also test result for a NULL buffer
and a non-zero size.
* tests/test-getline.c (main): Likewise.
* doc/posix-functions/getline.texi: Mention
[adding bug-gnulib, as the source of tar's getline replacement]
According to noordsij on 1/21/2010 6:37 AM:
Dear GNU tar maintainer(s) / fBSD gtar port maintainer(s),
The problem appears to be a difference in getline() behaviour in the fBSD
and GNU libc.
fBSD: The
caller may provide
Bruno Haible br...@clisp.org writes:
Some ideas:
1) Should the sockets.m4 module unconditionally add LIBSOCKET to LDADD?
2) Should the gnulib-tool generated Makefile.am add LIBSOCKET to LDADD?
No, LDADD has an effect on all executables. I don't want to link all my
programs against
Simon Josefsson wrote:
This may have been discussed before, but I don't recall a solution, so
maybe a new report will help.
Yes, in the meantime we all had time to think about it.
i586-mingw32msvc-gcc -g -O2 -o test-getdelim.exe test-getdelim.o
../gllib/libgnu.a
This may have been discussed before, but I don't recall a solution, so
maybe a new report will help.
Gsasl and gnutls uses the close, socket and getline modules from gnulib.
I get a problem when building gnulib's self-tests for mingw. You can
reproduce it by using:
rm -rf m
gnulib-tool --create
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 portability
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 could extend gnulib's
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 accommodate
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 wrappers to
ensure
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
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 is
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 they
-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. Should
-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.
We could
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 (getline): Protect prototype better.
--- getline.h 17
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 (getline
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 sync, since they are part of a
single gnulib module.
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.
Definitely. uClinux
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 environment
Paul Eggert [EMAIL PROTECTED] writes:
That patch (in
http://lists.gnu.org/archive/html/bug-gnulib/2005-07/msg00172.html)
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.
Thanks,
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 getline seem
for getline and getdelim.
2. The getndelim2 module is not modified.
3. I'm not sure the M4 magic is kosher.
4. The M4 tests and building appear to work on GNU/Linux, NetBSD, DEC
and HPUX. I haven't tested that the implementation works.
Index: modules/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
37 matches
Mail list logo
