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-egg...@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-9880a8839...@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