[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: Bruno Haible
Subject: Re: scratch_buffer.h, scratch_buffer_dupfree.c sync
Date: Thu, 03 Nov 2022 13:41:18 +0100

Florian Weimer wrote:
> > 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 for this clear statement, Florian.

So I was too optimistic when I wrote
  - "It looks like the 'scratch_buffer' could be useful to some programs
     outside of glibc." [1]
  - "dynarray looks useful" [2]

Here are proposed patches to rename the modules.

[1] https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00073.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg00042.html

2022-11-03  Bruno Haible  <bruno@clisp.org>

        dynarray: Rename to glibc-internal/dynarray.
        * modules/glibc-internal/dynarray: Renamed from modules/dynarray.
        * modules/glibc-internal/dynarray-tests: Renamed from
        * modules/regex (Depends-on): Update.
        * NEWS: Mention this change and the previous one.

2022-11-03  Bruno Haible  <bruno@clisp.org>

        scratch_buffer: Rename to glibc-internal/scratch_buffer.
        * modules/glibc-internal/scratch_buffer: Renamed from
        * modules/glibc-internal/scratch_buffer-tests: Renamed from
        * modules/canonicalize (Depends-on): Update.
        * modules/canonicalize-lgpl (Depends-on): Likewise.
        * modules/glob (Depends-on): Likewise.

Attachment: 0001-scratch_buffer-Rename-to-glibc-internal-scratch_buff.patch
Description: Text Data

Attachment: 0002-dynarray-Rename-to-glibc-internal-dynarray.patch
Description: Text Data

reply via email to

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