[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

From: Florian Weimer
Subject: Re: scratch_buffer.h, scratch_buffer_dupfree.c sync
Date: Thu, 03 Nov 2022 12:03:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]