Re: [PATCH 2/3] scratch_buffer: new module

[Paul Eggert]

Florian Weimer wrote:
> This configure test is invalid because __libc_scratch_buffer_grow is a
> GLIBC_PRIVATE symbol not part of the ABI.
>
> You really need to rename those __libc_* functions because they are in
> the internal glibc namespace.

Done by installing the first attached patch into Gnulib. This doesn't need any 
change to glibc: though it renames the Gnulib files that correspond to glibc, it 
does not change their contents.

It is an annoyance, though, that Gnulib-using apps now need another copy of the 
functions in question. How about publicizing that part of the glibc API, to 
avoid the duplication?

While looking into the above problem, I noticed a portability issue with 
platforms lacking getpwnam_r. Fixed in Gnulib in the 2nd attached patch.

And while looking into *that* problem, I noticed that the code needlessly saves 
and restores errno on platforms that have getpwnam_r. Fixed in Gnulib in the 3rd 
attached patch.

The last two patches should be ported back to glibc.

> struct scratch_buffer depends on a GNU C extension:
> assignment to an object changes its dynamic type.  It is not standard C.
>   Standard C only allows one way to allocate untyped memory, and that is
> malloc.

That should not be a problem, as Gnulib code regularly breaks those standard-C 
rules when it comes to memory allocation. The old glob.c broke those rules too, 
and the change should not make us any worse in that department. The code should 
continue to work on all practical platforms that I know about; if you are aware 
of any realistic counterexamples please let us know.

0001-scratch_buffer-don-t-use-private-glibc-API.patch
Description: Text Data

0002-glob-don-t-assume-getpwnam_r.patch
Description: Text Data

0003-glob-don-t-save-and-restore-errno-unnecessarily.patch
Description: Text Data