* 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
