bug#74427: tests/printf/printf-indexed failure on macOS

[Pádraig Brady]

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.
>
>
> > More problematically I think is it's also inconsistent with %s
> >
> >    $ src/printf '%s'
> >    $ src/printf '%s' ''
>
> I don't see a problem there. As per POSIX, missing string arguments are
> treated as empty strings, whereas missing numeric arguments are treated
> as zero.
>
>
> > 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@cs.ucla.edu/T/#u

For completeness I noticed a previous related dash discussion about this:
https://patchwork.kernel.org/project/dash/patch/62c16598-2d44-f4c9-991d-9880a8839786@inlv.org/#21564895

At the _shell level_, unset and empty variables are to be treated similarly,
and as per POSIX, for shells, uninitialized variables should be treated as 0


  dash -c 'unset x; echo $((x))'
  0
  $ dash -c 'x=; echo $((x))'
  0

I know shell arithmetic is separate to printf processing,
so just posting this for completeness and to perhaps aid
any discussions on the shell bug reports above.

cheers,
Pádraig