Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

[Florian Weimer <fweimer@redhat.com>]

* Bruno Haible:

> 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.

I must say I was surprised to see dynarray and scratch_buffer end up in
gnulib.  I never intended them to escape this way from glibc.  The
interfaces and their implementation are problematic in some ways, and I
can't recommend them for general use.

Thanks,
Florian