Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)
Gavin Smith wrote: > It is surprising it worked as well as it did with mixing the two different > struct definitions. Yes. Probably because the alignment only matters on sparc64 and ia64 machines, and because no new features were added to this module in 20 years. > Thanks for the detailed investigation. Will this be fixed in gnulib at > some point? Yes, I expect so. Bruno
Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)
On Tue, Nov 14, 2023 at 10:16:33PM +0100, Bruno Haible wrote:
> Sam James wrote:
> > > It appears that the obstack gnulib module is the culprit.
>
> I replied:
> > Therefore, if it is a bug in gnulib, it is also a bug in glibc.
>
> Sam was right. I was wrong. It is a bug in the 'obstack' gnulib module.
It is surprising it worked as well as it did with mixing the two different
struct definitions.
Thanks for the detailed investigation. Will this be fixed in gnulib at
some point?
> The root cause
> --
>
> Gnulib generally uses idioms for overriding functions that are safe to use
> in shared libraries and will avoid collisions. This is the business with
> REPLACE_FOO=1
> and
> #define foo rpl_foo
> and so on.
>
> But the Gnulib module 'obstack' has never been updated to use these idioms.
> It is still at the state of 1997 and uses a clunky _OBSTACK_INTERFACE_VERSION
> mechanism.
I get the impression it's not a very frequently used part of glibc.
> --- texinfo-7.1/tp/Texinfo/XS/gnulib/lib/obstack.h.bak2023-08-13
> 22:10:03.0 +0200
> +++ texinfo-7.1/tp/Texinfo/XS/gnulib/lib/obstack.h2023-11-14
> 20:30:55.584463250 +0100
> @@ -164,6 +164,12 @@
> # endif
> #endif
>
> +#define _obstack_begin rpl_obstack_begin
> +#define _obstack_newchunk rpl_obstack_newchunk
> +#define _obstack_allocated_p rpl_obstack_allocated_p
> +#define _obstack_free rpl_obstack_free
> +#define _obstack_memory_used rpl_obstack_memory_used
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
That's great, I'll apply this patch to the release branch and revert
the other change (using obstack_alignment_mask).
Re: c32width gives incorrect return values in C locale
On Wed, Nov 15, 2023 at 12:22:24AM -0800, Paul Eggert wrote: > On 2023-11-13 01:28, Patrice Dumas wrote: > > According to your mail > > https://lists.gnu.org/archive/html/bug-libunistring/2023-11/msg0.html > > > > char32_t is less portable > > That should be OK, if Gnulib provides a char32_t substitute that works well > enough. The mail you refer to merely says that literals like U'x' don't > work, but this is not a show-stopper for char32_t. Indeed, the solaris10 automatic build now compiles ok with char32_t with Gnulib uchar after the changes Gavin made. -- Pat
Re: c32width gives incorrect return values in C locale
On 2023-11-13 01:28, Patrice Dumas wrote: According to your mail https://lists.gnu.org/archive/html/bug-libunistring/2023-11/msg0.html char32_t is less portable That should be OK, if Gnulib provides a char32_t substitute that works well enough. The mail you refer to merely says that literals like U'x' don't work, but this is not a show-stopper for char32_t.
