Bernhard Voelker wrote:
> >> on openSUSE for Leap 16.0 on x86_64 [1] and aarch64 [2].
> >>
> >> Using coreutils-9.5 (which has gnulib 259829e78), glibc-2.40.
> >> ...
> 97 /* Test whether the utf8_to_local converter is available at
> all. */
> 98 if (!is_utf8)
> 99
On 12/6/24 14:24, Pádraig Brady wrote:
On 06/12/2024 07:13, Bernhard Voelker wrote:
On 11/19/24 19:31, Pádraig Brady wrote:
OK I've adjusted our test to use \u00032 instead,
The bug report was talking about Macos only, but now I'm seeing this failure
also
on openSUSE for Leap 16.0 on x86_64
On 06/12/2024 07:13, Bernhard Voelker wrote:
On 11/19/24 19:31, Pádraig Brady wrote:
OK I've adjusted our test to use \u00032 instead,
The bug report was talking about Macos only, but now I'm seeing this failure
also
on openSUSE for Leap 16.0 on x86_64 [1] and aarch64 [2].
Using coreutils-9.
On 19/11/2024 04:41, Grisha Levit wrote:
The u4 and U8 tests in tests/printf/printf-cov.pl fail on macOS 15:
u4...
printf: test u4: stdout mismatch, comparing u4.1 (expected) and u4.O (actual)
*** u4.1Mon Nov 18 23:30:03 2024
--- u4.OMon Nov 18 23:30:03 2024
***
*** 1
On 19/11/2024 17:34, Bruno Haible wrote:
Pádraig Brady wrote:
I would prefer to bypass the ASCII case if CODE >= 0 && CODE < 128.
However is that generally correct?
Yes, at least for CODE >= 32 && CODE < 128 it is correct.
This can be seen from the list of supported locale encodings in
gnulib/
Pádraig Brady wrote:
> and tested the attached code, which I'll push later.
Looks good, except for a typo in comment: Simplifiy → Simplify
Thanks.
Bruno
Pádraig Brady wrote:
> I would prefer to bypass the ASCII case if CODE >= 0 && CODE < 128.
> However is that generally correct?
Yes, at least for CODE >= 32 && CODE < 128 it is correct.
This can be seen from the list of supported locale encodings in
gnulib/lib/localcharset.h.
> Consider EBCDIC fo
On 19/11/2024 16:08, Bruno Haible wrote:
Pádraig Brady wrote:
On your macos 15 system, iconv() of 0x30 is failing to convert from utf8 to C,
and the fallback in unicodeio.c is outputting the \u0030.
Now I don't have access to macos to see exactly why that iconv() is failing,
The macOS iconv()
Pádraig Brady wrote:
> On your macos 15 system, iconv() of 0x30 is failing to convert from utf8 to C,
> and the fallback in unicodeio.c is outputting the \u0030.
> Now I don't have access to macos to see exactly why that iconv() is failing,
The macOS iconv() is unusable, since macOS 12. [1][2]
A
The u4 and U8 tests in tests/printf/printf-cov.pl fail on macOS 15:
u4...
printf: test u4: stdout mismatch, comparing u4.1 (expected) and u4.O (actual)
*** u4.1Mon Nov 18 23:30:03 2024
--- u4.OMon Nov 18 23:30:03 2024
***
*** 1
! 0
\ No newline at end of file
--- 1
10 matches
Mail list logo
