Hi Yuqi,
Yuqi Guo <gu...@ios.ac.cn> writes:
> Hello friends, do you have any idea about this?
Sorry, I forgot to respond. I'm moving this to bug-gnulib@gnu.org. I
don't know enough about docker but perhaps someone else can help.
The original report [1]:
> File:
>
> gnulib-tests/test-localeconv.c
>
> Code:
>
> ```
>
> struct lconv *l = localeconv ();
>
> ASSERT (l->frac_digits == CHAR_MAX);
> ASSERT (l->p_cs_precedes == CHAR_MAX);
> ASSERT (l->p_sign_posn == CHAR_MAX);
> ASSERT (l->p_sep_by_space == CHAR_MAX);
> ASSERT (l->n_cs_precedes == CHAR_MAX);
> ASSERT (l->n_sign_posn == CHAR_MAX);
> ASSERT (l->n_sep_by_space == CHAR_MAX);
>
> ```
>
> Problem:
>
> On RISCV, the `char` is unsigned. Thus, the `CHAR_MAX` is 255 instead of
> 127 on x86. However, the localeconv values remain the same on RISCV as
> x86 (the values are 127). This makes the> assertions fail on RISCV.
I asked what system and Yuqi says [2]:
> I use a RISCV QEMU emulator to compile and run the findutils package.
> The emulator was packed and published on Docker Hub by someone several
> months ago. You can get it by `docker pull
> xfan1024/openeuler:23.09-riscv64` and then start a docker container to
> easily use it. Note, you may need to have `qemu-riscv64-static`
> installed on your host system as this emulator is driven by it.
>
> Inside the emulator, I find that:
> (1) The system is openEuler-23.09
>
> (2) The libc is GNU libc (version 2.38), and the compiler is gcc (version
> 12.3.1)
The correct behavior is these values should be CHAR_MAX as described by
POSIX [3]:
The members with type char are non-negative numbers, any of which can
be {CHAR_MAX} to indicate that the value is not available in the
current locale.
Collin
[1] https://lists.gnu.org/archive/html/bug-findutils/2024-06/msg00036.html
[2] https://lists.gnu.org/archive/html/bug-findutils/2024-06/msg00039.html
[3] https://pubs.opengroup.org/onlinepubs/009695399/functions/localeconv.html
