GNU bug report logs - #74427
tests/printf/printf-indexed failure on macOS

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 74427 <at> debbugs.gnu.org, grishalevit <at> gmail.com
Subject: bug#74427: tests/printf/printf-indexed failure on macOS
Date: Tue, 19 Nov 2024 20:28:22 +0000

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, we want to treat them
> differently. Also, it makes sense to treat '' like ' '; we report an
> error for the latter so we should report it for the former too.

Well POSIX isn't explicit about the empty case.
The closest it specifies I think is:

  "If an argument operand cannot be completely converted into an
   internal value appropriate to the corresponding conversion specification,
   a diagnostic message shall be written to standard error"

But one could consider an empty argument as completely converted?

I'm not very strongly against the change,
it just seems a little inconsistent to me to error for the empty argument
to numeric conversion case, when we don't do that for strings.

Also I'm a bit worried about quoting consequences for shell scripts.
For example scripts with `printf '%d\n' "$int"` will start erroring if int is not defined,
whereas arguably less protected scripts with `printf '%d\n' $int` will behave (correctly) as before.

>> That's different to bash and dash.
> 
> AIX and Solaris 10 printf do things the right way (i.e., conform to
> POSIX) - not surprising as AIX at least has gone through POSIX
> conformance tests. I expect the GNU divergence from tradition was
> accidental, as it doesn't make sense for printf to treat '' differently
> from other non-numbers.
> 
> I filed bug reports for both Bash and Dash; see:
> 
> https://lists.gnu.org/r/bug-bash/2024-11/msg00149.html
> https://lore.kernel.org/dash/20241119193211.1585716-1-eggert <at> cs.ucla.edu/T/#u

For completeness ksh on Solaris 11 treats empty as 0

  solaris11$ printf --version
  version         printf (AT&T Research) 2009-02-02
  solaris11:~$ printf '%d\n' ''
  0

As does newer ksh:
  fedora40$ printf --version
  version         printf (ksh 93u+m) 2023-03-23
  fedora40$ printf '%d\n' ''
  0

Though I also see that ksh treats any non number as 0.

cheers,
Pádraig

Previous Next

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