[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]