[Top][All Lists]
[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_
- Re: [Bug-gnulib] getline & getline_safe, (continued)
- [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, 2003/07/18
- Re: [Bug-gnulib] getline & getline_safe,
Derek Robert Price <=
- 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
- Re: [Bug-gnulib] getline & getline_safe, Bruno Haible, 2003/07/31