Re: [Bug-gnulib] getline bugfix submitted via findutils

[David Newall]

Bruno,

On Sat, 2004-04-17 at 06:09, Bruno Haible wrote:
>> The error does occur in the current released version (ie 4.1.7)
> 
> IMO the fix should go into the function that calls getstr() or getndelim2().

There is no function getndelim2().  I'm pretty sure you're looking at a
later version of findutils.

> With the patch that you gave, when OFFSET > *LINESIZE, the first realloc
> call allocates OFFSET - *LINESIZE bytes with uninitialized memory. Does the
> caller handle a string, consisting of N initialized bytes, followed
> by OFFSET - N uninitialized bytes, followed by some initialized
> bytes, correctly?

It's not clear what happens because locate can move backwards in the
path buffer.  Consider the following code fragment from locate.c:

          if (c == LOCATEDB_ESCAPE)
            count += get_short (fp);
          else if (c > 127)
            count += c - 256;
          else
            count += c;

Count (which is the offset) is reduced when a character > 127 is read. 
For that matter, when LOCATEDB_ESCAPE is read count can also be reduced
but also it can be advanced over uninitialised buffer.  This looks like
some sort of common string compression technique, for example the
"front-compression" mentioned in locate's comments.


>  No it doesn't. A look at findutils-4.1.7/locate/locate.c
> line 322 reveals that, of course, it assumes that the whole line is
> initialized data.

Are you sure that's findutils-4.1.7 you're looking at?  Lines 320
through 324 of locate.c read:

          if (ferror (fp))
            {
              error (0, errno, "%s", dbfile);
              return 0;
            }

Looking at the current alpha release, 4.1.20, I see that major changes
have been made to findutils.  James said as much.  If it's close to
being released then there's no point in fixing 4.1.7.  (What happened to
the versions in between?  4.1.7 is ten years old.)

David