[PATCH] locale: align _nl_C_LC_CTYPE_class and _nl_C_LC_CTYPE_class32 arrays to uint16_t and uint32_t respectively

[Carlos O'Donell]

On 3/15/21 2:42 PM, Lirong Yuan via Libc-alpha wrote:
> steps to reproduce the problem: compile a program that uses ctype functions such as “isspace” for aarch64 with UBSan flag “-fsanitize=undefined” and run it on x86_64 machines with qemu user mode emulation.

Szabolcs,

Do you have any input on this?
 
> observed behavior: UndefinedBehaviorSanitizer reports misaligned-pointer-use in the program.

Yes, the char array could be misaligned with respect to a 16-bit value,
and should be aligned to the type that is expected from the interface e.g.

ctype/ctype.h:

 91 # define __isctype_f(type) \
 92   __extern_inline int                                                         \
 93   is##type (int __c) __THROW                                                  \
 94   {                                                                           \
 95     return (*__ctype_b_loc ())[(int) (__c)] & (unsigned short int) _IS##type; \
 96   }
 97 #endif

include/ctype.h:

 38 CTYPE_EXTERN_INLINE const uint16_t ** __attribute__ ((const))
 39 __ctype_b_loc (void)
 40 {
 41   return __libc_tsd_address (const uint16_t *, CTYPE_B);
 42 }

So we expect a uint16_t type and the respective alignment.

My expectation is that normally aarch64 simply handles the unaligned load without any problems,
but that it would be "better" if it were 16-bit aligned?

Is this the *only* case of misaligned pointers?

> solution: align the arrays defined in locale/C-ctype.c with correct data types as defined in ctype/ctype.h.
> 
> test suite regressions: none.

This looks technically correct, and the C locale is builtin so the layout
itself should be able to change without any problems.

I'd like to hear comments from Arm about this before accepting.

> Signed-off-by: Lirong Yuan <yuanzi@google.com>

We don't use DSOs in glibc, we assign copyright to the FSF, so this line would
be normally removed, and you as the git author remains.

See:
https://sourceware.org/glibc/wiki/Contribution%20checklist

You are covered by the Google copyright assignment so everything is accepted.

> ---
>  locale/C-ctype.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/locale/C-ctype.c b/locale/C-ctype.c
> index bffdbedad0..da2c8cc33c 100644
> --- a/locale/C-ctype.c
> +++ b/locale/C-ctype.c
> @@ -18,6 +18,7 @@
>  
>  #include "localeinfo.h"
>  #include <endian.h>
> +#include <stdalign.h>

OK.

>  #include <stdint.h>
>  
>  #include "C-translit.h"
> @@ -30,7 +31,7 @@
>     In the `_nl_C_LC_CTYPE_class' array the value for EOF (== -1)
>     is set to always return 0 and the conversion arrays return EOF.  */
>  
> -const char _nl_C_LC_CTYPE_class[768] attribute_hidden =
> +alignas(uint16_t) const char _nl_C_LC_CTYPE_class[768] attribute_hidden =

OK. Used directly by __ctype_b_loc.

>    /* 0x80 */ "\000\000" "\000\000" "\000\000" "\000\000" "\000\000" "\000\000"
>    /* 0x86 */ "\000\000" "\000\000" "\000\000" "\000\000" "\000\000" "\000\000"
>    /* 0x8c */ "\000\000" "\000\000" "\000\000" "\000\000" "\000\000" "\000\000"
> @@ -96,7 +97,7 @@ const char _nl_C_LC_CTYPE_class[768] attribute_hidden =
>    /* 0xf4 */ "\000\000" "\000\000" "\000\000" "\000\000" "\000\000" "\000\000"
>    /* 0xfa */ "\000\000" "\000\000" "\000\000" "\000\000" "\000\000" "\000\000"
>  ;
> -const char _nl_C_LC_CTYPE_class32[1024] attribute_hidden =
> +alignas(uint32_t) const char _nl_C_LC_CTYPE_class32[1024] attribute_hidden =

OK. Might be exposed via nl_langinfo and is internally uint32_t (thought directly
exposed __ctype32_b should not exist for aarch64 (verified not on abilist)).

>    /* 0x00 */ "\000\000\002\000" "\000\000\002\000" "\000\000\002\000"
>    /* 0x03 */ "\000\000\002\000" "\000\000\002\000" "\000\000\002\000"
>    /* 0x06 */ "\000\000\002\000" "\000\000\002\000" "\000\000\002\000"
> 
-- 
Cheers,
Carlos.