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.
