On Sat, 8 Feb 2025, 17:48 Robert Elz, <k...@munnari.oz.au> wrote:
>
> | and if the correspondence with strtol() is to be taken at face value,
> | this would likewise imply that empty string is a valid representation
> for
> | zero, since strtol() reports that it has converted the entire string in
> | that case.
>
> Nonsense. If one does:
>
> errno = 0;
> num = strtol(str, &ep, 10 /* or any other valid base, incl 0 */);
>
> then strtol has failed if any of the following are true:
>
errno != 0 /* typically ERANGE from overflow */
> ep == str /* no digits were converted, cannot be a C
> const */
>
You're choosing to include this condition on the tacit assumption that no
extensions are permitted. I make the opposite choice -- to exclude it --
because I find allowing empty-as-zero is a *useful* extension because it
makes my code less convoluted and therefore less error-prone
Arguing for consistency *primarily* with the C standard is a retrograde
step; I prefer to argue for internal consistency with Bash itself. As I
have noted previously, there are many cases where Bash 5.2 silently accepts
an empty string as a numeric zero, and just one where it complains
(introduced a few years ago). Which other ones do you think should be
removed? How much more inconsistent should Bash become?
Bash has lots of extensions to POSIX (and C), and some of them are even
documented. Why remove this particular one?
(Arguing about printf potentially being an external command is pointless
when its -v option is impossible to implement in an external command.)
Give up, you're wasting your time arguing this.
>
Hell no.
You're making an entirely circular argument that empty-as-zero is invalid
because it's invalid - based on a choice to exclude extensions.
(At this point I'm half expecting a retort along the lines of "it's not an
extension, it's an error".)
You might not like my choice, but it's not like I'm forcing you to use
empty to represent numeric zero; whereas you want to break my code with no
switch to turn off the warning (once at a single point, not every time I
use printf).
If you want it to be printed as an integer, then
(*snipped* lots of suggestions which miss the point)
This wasn't a request for suggestions on how to writing code that will work
under this new constraint.
My primary concern is that changes like this force audits of shell scripts
that are hitherto working exactly as intended, lest we risk interruptions
to production.
I'm making a big deal of this not because this particular case is likely to
cause real problems, but because it's part of a bigger pattern, and I'm
getting sick of code needing to be re-audited every time someone decides to
remove a feature or extension based on "I can't think of a use for it
therefore it must be a bug rather than an extension".
If you can't think of a use for it, that merely shows your lack of
imagination.
ps: I fixed NetBSD's printf to do this correctly a while ago. That has
> produced exactly 0 complaints about scripts now failing which used to work.
> Or should I instead say: that has produced exactly complaints about ... ?
>
That only proves it's low incidence, not non-existent.
Once one finds that a script is broken, it's MUCH quicker just to adjust it
to accommodate the change/breakage in the shell than to complain about it
to the shell maintainer and wait for a fix.
Unless a broken script was under actively used by or maintained by a member
of the maintainers of NetBSD printf, they would very likely never hear
about it.
But thanks for the idea: I will make a point of filing a bug report every
time I get woken by pager because a change to the shell breaks a
working-as-intended script, even if it's one that I already know about.
If Bash is going to keep on making breaking changes, then we should be
strongly recommending to packagers that they should ship multiple versions
of Bash, not just always "latest", so that scripts can elect to use
"#!/bin/bash5" or "#!/bin/bash4". And changes that introduce new
prohibitions or warnings, or retire old features, should always get a new
major version number, so that scripts that start with '#!/bin/bash5'
doesn't mysteriously break on some point release of Bash 5.
-Martin
>
