Re: getline & getline_safe

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: [email protected]

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_