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:
> and tested the attached code, which I'll push later.
Looks good, except for a typo in comment: Simplifiy → Simplify
Thanks.
Bruno
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/
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
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
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
