Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

[Bruno Haible]

Paul Eggert wrote:
> Yes, it's a nontrivial merge. However, I think we can still sync 
> LIBC/include/scratch_buffer.h. I installed the attached patch

It's a backward-incompatible change: A documented function is now
suddenly gone, without a deprecation period. Let me document it in
NEWS.

I think this has some consequences on how we deal with glibc internals
in Gnulib. We exported the 'scratch_buffer' module, thinking that it's
a welcome addition to the Gnulib API. But we are seeing that
either
   the glibc people did not know that this API is exported from Gnulib,
or
   they knew but ignored the fact that this API is exported from Gnulib.
Could anything be done to avoid such things from occurring again?

If not, then I'm inclined to view this way of exporting glibc internals
as a failed experiment. And as a consequence, we should only take and
export glibc code if it is
  - either a POSIX API, or
  - documented in the glibc manual.
And if we have Gnulib modules that contain glibc-internal code, we should
make it clear that it is not Gnulib public API.

In other words, I'm suggesting to rename the modules
  scratch_buffer -> glibc-internal/scratch_buffer
  dynarray       -> glibc-internal/dynarray


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

        scratch_buffer: Document last change.
        * NEWS: Mention last change.

diff --git a/NEWS b/NEWS
index 840564703a..327fc8ceee 100644
--- a/NEWS
+++ b/NEWS
@@ -74,6 +74,8 @@ User visible incompatible changes
 
 Date        Modules         Changes
 
+2022-11-02  scratch_buffer  The function 'gl_scratch_buffer_dupfree' is 
removed.
+
 2022-09-10  stdbool         This module now assumes C99 and provides C23,
                             instead of providing C99.  For the old behavior,
                             use the already-deprecated stdbool-c99 module.