On 11/2/22 19:37, Bruno Haible wrote:
In other words, I'm suggesting to rename the modules
scratch_buffer -> glibc-internal/scratch_buffer
dynarray -> glibc-internal/dynarray
I don't see any problem with that, since as far as I know the only
current users of the two modules are gli
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
On 11/2/22 15:37, Karl Berry wrote:
1) LIBC/include/scratch_buffer.h has introduced some substantial changes
over GNULIB/lib/malloc/scratch_buffer.h. I'm not sure if it is safe
to sync them any more. Especially because:
2) LIBC/nalloc/scratch_buffer_dupfree.c no longer exists. There is no
such
1) LIBC/include/scratch_buffer.h has introduced some substantial changes
over GNULIB/lib/malloc/scratch_buffer.h. I'm not sure if it is safe
to sync them any more. Especially because:
2) LIBC/nalloc/scratch_buffer_dupfree.c no longer exists. There is no
such file in libc any more.
Paul, anyone,
On Tue, 1 Nov 2022 at 22:24, Bruno Haible wrote:
>
> But first, the obligatory question: Can't you move the package to GPLv2+?
>
As you guessed, I can't (though it might be possible to get the original
authors to, I haven't asked).
> That's what would be most in line with GNU policies, since 2
