GNU bug report logs - #74428
tests/printf/printf-cov failure on macOS

Previous Next

Package: coreutils;

Reported by: Grisha Levit <grishalevit <at> gmail.com>

Date: Tue, 19 Nov 2024 04:42:01 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 74428 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org, Pádraig Brady <P <at> draigbrady.com>
Cc: 74428 <at> debbugs.gnu.org, Grisha Levit <grishalevit <at> gmail.com>
Subject: Re: bug#74428: tests/printf/printf-cov failure on macOS
Date: Tue, 19 Nov 2024 18:34:43 +0100
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 for example, with something like:
> 
>    LC_ALL=EBCDIC-US env printf '\u0030\n'
> 
> Now that's not supported anyway on my Fedora 40 system at least,
> but perhaps it might be in some setups?

No, it's not supported anywhere. The last platform that significantly
uses EBCDIC is IBM z/OS, and there the environment for C programs is
based on ASCII (i.e. the runtime library performs conversions between
ASCII-encoded in-memory data and EBCDIC-encoded disk data on the fly). [1][2]

That's also the reason why no one ever reported a problem with gperf-
generated C code, that assumes an ASCII-compatible encoding.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnu-libiconv/2023-04/msg00019.html
[2] https://lists.gnu.org/archive/html/bug-gnu-libiconv/2023-05/msg00002.html







This bug report was last modified 220 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.