bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] getline & getline_safe


From: Derek Robert Price
Subject: Re: [Bug-gnulib] getline & getline_safe
Date: Fri, 18 Jul 2003 09:33:59 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1

Bruno Haible wrote:

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 :-(


No problem.  You are responding now.  :)

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.


Now that should be the case, though the way my patch is currently configured, it is now getndelim2 that is always installed. I was waiting for more discussion with you before I changed my getline & getnline to #include getndelim2 as you did. If I do this, it will mean potentially 3 copies of the same code on systems without glibc which use all three functions and 2 copies on any machine that uses either getnline or getndelim and that uses getndelim2.

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!


:)

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.


I still don't agree. In the single case where the number of characters read (the return value of the function) is the same as the character limit passed to it, the caller can test the last character (ignoring the NUL byte) of it's buffer to see if it contains a delimiter or not. Thus, with a character limit specified, the edge case is detectable and can be dealt with in something like a typical while(read) loop, where each time the buffer is filled, it is dealt with and the next block of bytes are read until the caller is satisfied.

In your case, where the allocation limit for the buffer is specified, and the tail of a long line is thrown away, the edge case is always an error and the byte cannot be recovered.

I also think specifying a maximum number of characters to read is the more intuitive interface. I think a caller is more likely to be worried about new characters read than how much memory is allocated down to the last few bytes. That is how CVS is using this function. It is just setting an arbitrary limit on the number of characters that will be read as a line from an authentication stream in order to thwart denial of service attacks.

Derek

--
               *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
--
The Pledge of Allegiance does not end with "Hail Satan".
The Pledge of Allegiance does not end with "Hail Satan".
The Pledge of Allegiance does not end with "Hail Satan"...

         - Bart Simpson on chalkboard, _The Simpsons_






reply via email to

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