bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $((expr)) allows the hexadecimal constant "0x"


From: Martin D Kealey
Subject: Re: $((expr)) allows the hexadecimal constant "0x"
Date: Thu, 30 Nov 2023 20:18:22 +1000

Apropos the intentional breakage of ((10#$X)) I wrote (back in June 2023):
> > Is there any chance this can be reversed before it becomes an official
release?
to which Chet replied:
> This happened years ago.

I have to admit that I'm finding that being a maintainer for a large suite
of Bash scripts is a very frustrating experience because Bash keeps
shifting under me.

Many (perhaps most) script maintainers don't hear about a change until
several years after it's incorporated into an official release of Bash,
because that's how long it takes for it to percolate through several tiers
of release processes and actually get installed. We test our scripts for
backwards compatibility when we make changes, but most of us don't have
automated systems to check for *forwards* (or *anticipatory*) compatibility.

This is especially problematic when combined with "every release of Bash is
valid forever". Without the ability to firmly say "ooops, that version of
Bash was broken, everyone please stop using it", this makes for a terrible
experience for maintainers of scripts that then have to run where someone
has chosen the version of Bash that's available.

If there's a bug tracking system beyond "threads in a mailing list", I'd
like to know how I can get access to it.

The "roadmap" seems to consist of Chet occasionally announcing that some
refactoring has been done or is in progress; if there's a list of future
plans somewhere, I'd love to see it clearly published.

Bug triage seems to consist of a day or so's discussion in this list, but
when a solution is proposed it usually gets little or no discussion, and no
code review whatsoever; often we only get "this will be fixed in [an
upcoming] release", with no mention of *how* a problem will be fixed.

There's nobody actively canvassing users, asking "will this [insert
detailed proposal] break your code?". And no, telling this mailing list is
NOT enough, because this list is unrepresentative of maintainers of Bash
scripts and other Bash users. (About now Chet is shrugging his shoulders
and saying "what else can I do". The fix for that is not to have the whole
project crammed into one human's brain. And yes, I do volunteer to help
sort this out.)

(Aside: even as an "experienced" Bash user, I didn't join this list until
relatively recently because I was under the impression that it was only for
people who actually *fixed* the bugs in Bash, not merely complained about
them. A key reason I believed this was because this list is the target
address for the "bashbug" reporting script. Perhaps this list should be
renamed "bash-testers", if that's its true purpose.)

End-of-life dates for previous versions should be promulgated as soon as
possible. I have my own idea of what they should be, but I'd like to hear
*how* other people would choose their dates.

When I said:

> > This change will break scripts that use $((10#$somevar)) to cope with
> > somevar having leading zeroes OR BEING EMPTY.


Chet replied:

> this clearly invalid syntax


"Clearly Invalid" is a matter of perspective. To me "no digits at all" is
the MOST logical way to write value zero, being the logical result of
"remove leading zero digits". (I may be sufficiently atypical that nobody
on this list agrees with me, but I'm definitely not unique globally.)

That change introduced an inconsistency into Bash:

 X= ; ((X == 0))  # true
 X= ; ((10#$X == 0)) # was true, now broken

I liked it better how it was.

(From a language design point of view, the only practical limitation to
treating an empty string as numerically zero is that an empty string needs
to be a recognisable lexical token; this is not the case in human
languages, which is why we write "0" instead, but happily in most computer
languages an empty string is indeed trivially differentiable from the
absence of any token. Bash is the exception in that $x may expand to one,
many, or no tokens, depending on context, but in *this* context it's clear.)

Chet said:

> You might be interested in the discussion:


> https://lists.gnu.org/archive/html/bug-bash/2018-07/msg00015.html
> https://lists.gnu.org/archive/html/bug-bash/2019-06/msg00039.html


I read that and wept.

Just because someone didn't understand the difference between a single
token and an entire arithmetic expression doesn't mean "change the
definition of a token" was the right response.

(What I really don't get is why were they trying to use an explicit decimal
radix on something that was the result of a previous arithmetic expansion,
and therefore already guaranteed to be decimal?)

Even if this seemed to be clearly the reasonable response, why was there no
clear & separate solicitation of feedback for "we propose to invalidate
"10#" without any following digits"?

>> However, a somewhat similar situation with hex prefix,
> >> 0xDIGITS, still allows just "0x" as a valid zero constant.
> >>
> >> Not sure whether this should be considered a bug,
> >> and whether it's worth fixing - just letting you know.
> >>
> >
> > No, definitely not. It's established behaviour, and should not be removed
> > without an explicit shopt.
>
> It's clearly a bug -- it's an invalid C constant. I suppose we can call it
> an extension.
>

"Clearly a bug" is a matter of opinion, especially when this old behaviour
creates no security vulnerabilities and conflicts with no historical,
existing or proposed syntax. Like all extensions that people are actually
using, it should not have been gratuitously removed.

I've been a stalwart supporter of Bash for 30 years, and I've recommended
it ahead of zsh because its POSIX support is better. By now the only point
in using Bash is either its full POSIX support, or its commitment to long
term backwards compatibility.

Clearly I'm been wrong about the latter.

Sometimes there is a compelling valid case for changing behaviour that is a
security nightmare, but rarely, and "this is obviously a mistake" has
repeatedly been the weakest of cues for a wrecking backwards compatibility.
Just because the hundreds of people on this list can't think of a valid use
for some "mistake" does not mean that among the millions of users nobody
else has found one.

Chet please tell me, after 30 years of me using Bash, why should I use Bash
for anything, if what I write now is going to break in 5 or 10 years?

Lately I've struggled with my conscience when I've recommended Bash as the
shell of choice for new users; perhaps should I be campaigning to kill off
Bash entirely?

-Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]