[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] getline & getline_safe
From: |
Bruno Haible |
Subject: |
Re: [Bug-gnulib] getline & getline_safe |
Date: |
Fri, 18 Jul 2003 12:40:16 +0200 |
User-agent: |
KMail/1.5 |
Hi Derek,
Sorry that I ignored your patch with title 01-getnline.diff: it (and
the followup by Steve McIntyre) didn't reach my mailbox, due to a
power failure at my mail host on Wednesday. I've very sorry about it,
that's not the way I use to work :-(
> > The way I've done it now, programs which need both getline() and
> > getnline()
> > will end up with two copies of the same code, on non-glibc systems. OTOH,
> > if you do it differently, you end up with getnline() code on glibc
> > systems, for programs which only need getline(). The latter seems worse
> > to me.
>
> On the contrary, you would only end up with both functions on non-glibc
> systems the way I wrote the code.
Anyway: the important case to consider are packages which use getline()
or getnline() but not both. They should not be penalized.
> I merged my changes, carried through some of
> yours, and fixed a few bugs in my original patch which also existed in
> yours
Thanks for this work!
> I also installed getndelim2 as a separate module since Jim Meyering
> requested it.
Yes, when we removed getstr() a few months ago, we weren't aware that
coreutils/src/cut.c was using it.
> Oh, I also switched limit to be a limit on the number of characters to
> read rather than the amount of memory to allocate.
This is broken, because it means that getnline() simulates a delimiter
where none was seen. In other words, the next call to getline() will
return the _remainder_ of the first long line of text, instead of the
second line. For line-oriented protocols this is just broken. (Assume
that in a mail I write "foobar...[many chars] From: fakedsender"
and you interpret this "From: " as being the beginning of a new mail.
Just broken.
OK, throwing away the tail of a long line is also broken. But not as much
as pretending that a newline was present when there was none.
> It is easy enough
> for the caller to determine limit from linesize if her intentions are to
> limit memory
I don't follow you here. getnline() is designed to do all it needs. The
caller will do no additional checking before or after the call.
Bruno
- Re: [Bug-gnulib] getline & getline_safe, (continued)
- Re: [Bug-gnulib] getline & getline_safe, Derek Robert Price, 2003/07/15
- Re: [Bug-gnulib] getline & getline_safe, Paul Eggert, 2003/07/15
- 01-getnline.diff (was Re: [Bug-gnulib] getline & getline_safe), Derek Robert Price, 2003/07/16
- Re: 01-getnline.diff (was Re: [Bug-gnulib] getline & getline_safe), Steve McIntyre, 2003/07/16
- Re: 01-getnline.diff (was Re: [Bug-gnulib] getline & getline_safe), Derek Robert Price, 2003/07/16
- [Bug-gnulib] Re: 01-getnline.diff, Jim Meyering, 2003/07/17
- Re: [Bug-gnulib] getline & getline_safe, Bruno Haible, 2003/07/17
- Re: [Bug-gnulib] getline & getline_safe, Bruno Haible, 2003/07/17
- Re: [Bug-gnulib] getline & getline_safe, Derek Robert Price, 2003/07/17
- Re: [Bug-gnulib] getline & getline_safe, Derek Robert Price, 2003/07/17
- Re: [Bug-gnulib] getline & getline_safe,
Bruno Haible <=
- Re: [Bug-gnulib] getline & getline_safe, Derek Robert Price, 2003/07/18
- Re: [Bug-gnulib] getline & getline_safe, Bruno Haible, 2003/07/18
- Re: [Bug-gnulib] getline & getline_safe, Derek Robert Price, 2003/07/18
- Re: [Bug-gnulib] getline & getline_safe, Bruno Haible, 2003/07/24
- Re: [Bug-gnulib] getline & getline_safe, Derek Robert Price, 2003/07/24
- Re: [Bug-gnulib] getline & getline_safe, Bruno Haible, 2003/07/24
- Re: [Bug-gnulib] getline & getline_safe, Derek Robert Price, 2003/07/25
- Re: [Bug-gnulib] getline & getline_safe, Bruno Haible, 2003/07/28
- Re: [Bug-gnulib] getline & getline_safe, Jim Meyering, 2003/07/28
- Re: [Bug-gnulib] getline & getline_safe, Derek Robert Price, 2003/07/31