On 19/11/2024 20:02, Paul Eggert wrote:
On 2024-11-19 09:53, Pádraig Brady wrote:
Do we really want to treat NUL and NULL strings differently?
$ src/printf '%d\n'
0
$ src/printf '%d\n' ''
printf: ‘’: expected a numeric value
0
Both behaviors are required by POSIX, so yes,
On 19/11/2024 21:48, Paul Eggert wrote:
On 2024-11-19 12:28, Pádraig Brady wrote:
But one could consider an empty argument as completely converted?
No, because POSIX says the argument must be a C integer constant, and
empty strings are not C integer constants. Similar reasoning applies for
flo
On 2024-11-19 12:28, Pádraig Brady wrote:
But one could consider an empty argument as completely converted?
No, because POSIX says the argument must be a C integer constant, and
empty strings are not C integer constants. Similar reasoning applies for
floating point specs like %g, where POSIX
On 19/11/2024 20:02, Paul Eggert wrote:
On 2024-11-19 09:53, Pádraig Brady wrote:
Do we really want to treat NUL and NULL strings differently?
$ src/printf '%d\n'
0
$ src/printf '%d\n' ''
printf: ‘’: expected a numeric value
0
Both behaviors are required by POSIX, so yes,
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 2024-11-19 09:53, Pádraig Brady wrote:
Do we really want to treat NUL and NULL strings differently?
$ src/printf '%d\n'
0
$ src/printf '%d\n' ''
printf: ‘’: expected a numeric value
0
Both behaviors are required by POSIX, so yes, we want to treat them
differently. Also, it m
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()
On 2024-11-19 07:10, Pádraig Brady wrote:
I've not got access to a macos system to test currently,
but the attached should address this.
That patch addresses only the empty string, not other strings that
cannot be converted (e.g., a string consisting of a single space). This
turns out to be a
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
On 19/11/2024 04:38, Grisha Levit wrote:
See the following two chunks from the test suite log on macOS 15:
+ printf_check ' 0 1 ' '%100$*d %s %s %s\n' 4 1
+ cat
+ shift
+ env printf '%100$*d %s %s %s\n' 4 1
printf: '': Invalid argument
+ fail=1
+ printf_check_err 'printf: '\''A'\'': expected
12 matches
Mail list logo
