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 a numeric value' '%0x2$s %2$s\n' A B
> + cat
> + shift
> + returns_ 1 env printf '%0x2$s %2$s\n' A B
> 02$s B
> + compare exp out
> + compare_dev_null_ exp out
> + test 2 = 2
> + test xexp = x/dev/null
> + test xout = x/dev/null
> + return 2
> + case $? in
> + compare_ exp out
> + LC_ALL=C
> + diff -u exp out
> --- exp	2024-11-18 23:32:01.486843241 -0500
> +++ out	2024-11-18 23:32:01.492438694 -0500
> @@ -1 +1 @@
> -printf: 'A': expected a numeric value
> +printf: 'A': Invalid argument
> + fail=1

This is due to inconsistency in how strtol and strtoimax operate on macos.
The man page for those on macos states:

   "If no conversion could be performed, 0 is returned and the global variable errno   is set to EINVAL (the last feature is not portable across all platforms)."

So in particular, we'll have to handle the NUL string in code,
to ensure it returns 0, and adjust the test to treat EINVAL
like "expected a numeric value".

I've not got access to a macos system to test currently,
but the attached should address this.

Marking this as done.

thanks,
Pádraig