Re: $(( )): binary/unary VAR/NUM inconsistency

[Martin D Kealey]

On Sat, 9 Jul 2022, 02:08 Chet Ramey, <chet.ramey@case.edu> wrote:

> On 7/8/22 11:03 AM, Steffen Nurpmeso wrote:
>
> > So you seem to use your own itoa, and here is (another) bash bug.
>
> Yeah, that's where stricter integer constant parsing would flag an error.
> It's just an extension; bash handles everything POSIX says it should
> handle. It might be worth catching that case, but, then again, nobody has
> ever reported it before now.
>
> > I think the POSIX people were talking about this; Eric Blake?
> > In this hindsight bash should bail with syntax error due to 0x:
>

I would urge extreme caution in removing functionality like this. I've had
the nightmare of finding that Bash removed functionality that I relied on,
because a group collectively lacked the imagination to see how it might be
used in ways that were neither bugs nor impediments to maintenance.

Some might think that changing the expression parser so that a bare "0x" is
rejected would be harmless at worst, and helpful against writing bugs. They
would be wrong. Writing "0x$var" is an established if uncommon idiom that
currently exhibits the same "empty is zero" behaviour as we get when
writing "var" without a radix prefix.

But my real point is that I shouldn't have to come here and make that
point; rather, avoiding breaking changes, even "in the name of making
scripts less buggy", should be the standing policy.

-Martin

PS: For those who wonder what change I'm referring to…

The change to "break" and "continue" so that they would refuse to act on a
loop outside the current function being a case in point. Apparently
"nobody" could see how the previous behaviour might be useful, other than
"to write bugs", and "everyone" thought that all possible uses must
necessarily be inadvertent bugs, and so the feature was removed.

But that change broke all my my "break_when_xxx" functions, and with them
my tab completion function for "ip", which of necessity comprises a fairly
complex stateful parser. In particular, its core is a case statement with
hundreds of cases and they all need the same conditional break when
reaching the word being expanded, so it made sense to encapsulate that in a
well-named function.

And I didn't find out until my OS updated its version of Bash several years
after that change to Bash itself, by which time it was way too late to
unwind the change to Bash and I had to rewrite large swathes of code to
cope with the installed base of Bash.