Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

[Bruno Haible]

Hi Paul,

Paul Eggert wrote:
> > In other words, I'm suggesting to rename the modules
> >    scratch_buffer -> glibc-internal/scratch_buffer
> >    dynarray       -> glibc-internal/dynarray
> 
> I don't see any problem with that, since as far as I know the only 
> current users of the two modules are glibc-related modules in Gnulib 
> itself.

Yes, as far as I can see, no packages have started to use these two
modules yet.

> However, if in the future programs find these two modules 
> useful, I suppose we'll need to rename them back.

No, I don't think this is going to fly, since we would be offering an API
for use, for which we cannot guarantee a reasonable degree of stability.

The liaison between Gnulib and Glibc is mostly you. If the glibc people
want to make changes to intprops.h, idx.h, filename.h, or the regex code,
you will certainly be aware of it, and be able to prevent breakage for
Gnulib users.

But when it comes to scratch_buffer or dynarray code, this week's experience
has shown that we cannot count on as much care for Gnulib users. Rather,
the mindset on the glibc side seems to be: "This is glibc internal code;
we can refactor / reshuffle / trim it as we like." [1][2]

So, if we want to offer a Gnulib module from glibc-internal code, it would
be our job to maintain compatibility across glibc's refactorings. In this
particular case, it would have meant to add the scratch_buffer_dupfree.c
as a Gnulib-owned source file. But it the long run, this is going to be
a growing maintenance effort. (We have a similar situation: gettext's libintl
is derived from glibc/intl/, and it's a continuing effort to keep the two
more or less in sync.)

Therefore I agree with what you did yesterday: remove scratch_buffer_dupfree.c
from Gnulib, since glibc dropped it.

But it means that we cannot promise that these .h files are even remotely
stable APIs.

Bruno

[1] https://sourceware.org/pipermail/libc-alpha/2022-October/143030.html
[2] https://sourceware.org/pipermail/libc-alpha/2022-October/143033.html