Re: [PATCH 1/6] canonicalize-lgpl: fix EOVERFLOW bug

[Paul Eggert]

On 12/18/20 6:13 AM, Adhemerval Zanella wrote:
> The same tests I pointed out on BZ#24970 comment #2 still fails with gnulib
> version 0aa8ef424.  I am not sure if it would be better to adapt my original
> patchset to use scratch_buffer (which seems originally a better idea) or if
> we can work towards fixing on gnulib.

My idea is to get it working with Gnulib (which has its own constraints) and 
then come up with a set of patches for glibc (which has even more 
constraints and so is harder to work with). We're not done with this of 
course. Some of the work involves making Gnulib act more like modern glibc, 
to make merging easier. I have some more ideas along those lines, by adding 
eloop-threshold.h and shlib-compat.h to Gnulib.

From a glibc point of view I think scratch buffers are the way to go here; 
they avoid some problems on the Hurd where PATH_MAX is not defined, and they 
have good performance for the typical case on the more-typical platforms 
that define PATH_MAX. When I tried to avoid using scratch buffers I found 
that the extra hassle dealing with malloc/free and stack buffers myself 
outweighed the overhead of using scratch buffers.

I also looked at glibc's dynarray.h which seems to be designed to supplant 
scratch_buffers, but dynarray seems oriented to just one use case (extending 
buffers just one item at a time) and that doesn't match what canonicalize 
wants to do.

As for simply forking between Gnulib and glibc, I'm not yet convinced that's 
the right way to go here. The glibc code had bugs that Gnulib will fix and 
vice versa, and it's good that we're ironing them out.