Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

[Gavin Smith]

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.bak        2023-08-13 
> 22:10:03.000000000 +0200
> +++ texinfo-7.1/tp/Texinfo/XS/gnulib/lib/obstack.h    2023-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).