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

From: Pádraig Brady <[email-masked]>
Date: Tue, 19 Nov 2024 22:16:37 +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.
> 
> 
>> 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/[email-masked]/T/#u

For completeness I noticed a previous related dash discussion about this:
https://patchwork.kernel.org/project/dash/patch/[email-masked]/#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