On 11/3/22 13:40, Karl Berry wrote:
Whatever happens, can one of you make the desired changes in gnulib?
Already done and installed, here:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=ddfcbc95a6be3ddc588a93f21edb69cc7c214d9c
As part of that patch, I did the same sort of sync that y
Paul Eggert wrote:
> > Here are proposed patches to rename the modules.
>
> Thanks, those look good to me too.
Thanks for the review. Pushed.
Bruno
Whatever happens, can one of you make the desired changes in gnulib? I
have never tried to follow the glibc/gnulib stuff. This one is above my
pay grade :). I just blindly sync the changes ... --thanks, karl.
* Paul Eggert:
> What problems do you see with the interfaces, and are there efforts to
> come up with a better API? The need is there in GNU apps, each of
> which tends to roll its own code here.
dynarray has an aliasing violation in its implementation. The embedded
pointer should be void * (no
On 2022-11-03 05:41, Bruno Haible wrote:
Here are proposed patches to rename the modules.
Thanks, those look good to me too.
On 2022-11-03 04:03, Florian Weimer wrote:
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.
They escaped from glibc because they're used by code shared with Gnulib
(e.g., canonicalize.c).
The
interfaces an
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 implementatio
* 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."
Hi Paul,
Paul Eggert 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 a
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,
13 matches
Mail list logo
