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

[Chet Ramey]

On 12/11/23 7:23 PM, Martin D Kealey wrote:
> On Mon, 11 Dec 2023 at 06:55, Chet Ramey <chet.ramey@case.edu 
> <mailto:chet.ramey@case.edu>> wrote:
>
>     It came up as a bug report in
>
>     https://lists.gnu.org/archive/html/bug-bash/2019-06/mstheng00042.html
>     <https://lists.gnu.org/archive/html/bug-bash/2019-06/msg00042.html>
>
>     (part of the followup discussion after the second linked thread above)
>     and the consensus among those who participated was that it was a good
>     thing to prevent base# without any digits from silently being treated
>     as 0.
>
>
> The wrap-up at the end of that discussion was this:
>
>     /I'm not sure how relevant that language is to integer constants in
>     expressions. I could also note that the language describing the base#n
>     syntax only talks about digits, letters, `@', and `_'. The bash
>     definition of arithmetic evaluation is taken from C. That includes
>     integer constants, and, while the base#value syntax clearly extends the
>     C definition of a constant, the `-' (and `+', FWIW) is still an
>     operator as defined by C./
>
>
> One could be forgiven for taking that to mean "this is behaving as expected 
> and won't be changed".

In the sense that you can't have an operator (`-') in the middle of an
integer constant. That wasn't going to change. The issue then became how
to prevent the same thing from happening to other users, and whether
silently treating no digits following the `#' as 0 was actually helpful,
since it ran counter to the documentation.

>     Do you think there would have been more discussion in different
>     circumstances?
>
>
> That entire discussion was between 4 people, and started and finished in 
> less than a week.
> Anyone who happened not to be around would have missed it, including me.
>
> Can a consensus among 4 people really be fair and representative of 
> millions of Bash users?

Participation has always been based on the number of interested
participants. The discussion about a particular bug report is no different.

>     Would you have participated, considering there's no sign of you on the
>     bug-bash list between 2016 and 2020?
>
>
> When the instructions say "send bug reports to X-bugs", it's natural to 
> assume that the primary audience for X-bugs is the people who fix bugs, and 
> other people should stay away. So for a long time I didn't join this list 
> because I wasn't in a position to contribute as a fixer.

"The discussion list `bug-bash@gnu.org' often contains information
about new ports of Bash, or discussions of new features or behavior
changes that people would like."

That's from the README.

"Suggestions and `philosophical' bug reports  may
 be  mailed  to  bug-bash@gnu.org  or  posted  to  the  Usenet newsgroup
 gnu.bash.bug."

That's from the man page. The info document has the same language.

The web page on gnu.org says

"<bug-bash@gnu.org> (web interface) is used to report bugs or discuss most 
aspects of developing Bash."

These imply that bug-bash isn't restricted to bug reports.

> Of course, that's not the only reason why people don't participate: 
> sometimes real life gets in the way and we don't have time to participate, 
> sometimes for weeks on end.

Sure, everyone has competing interests.

> But yes, I would have participated had I known this discussion was going on.

Maybe. None of us can go back. All you can do is move forward.

> In most projects this lack of discussion wouldn't matter: after the 
> discussion comes a proposed code change, and then code review, and then 
> even after release, it's an "experimental feature that may be retracted".

Features appear in the devel branch for months before they get included
in a formal release. There is ample opportunity to read the change logs,
look at the referenced discussions (nearly all changes are annotated with
the name of the person who suggested or reported them), look at the code,
and have a discussion. There are a number of people on here who report
bugs and ask questions about the devel branch. It does require effort.

> When we don't have those extra steps, and every release of bash is 
> "forever", yes, we need more considered discussion up front.

Those extra steps are the product of effort, see above.

If you want to change the distro policy of shipping and "supporting" old
versions (Apple is by far the most egregious offender here), or not moving 
to new versions in a timely-enough fashion, or only looking at changes
when I put out a release candidate, then it seems like you'd need to talk
to the distros or vendors. I support only the current release.

I talked about that in

https://lists.gnu.org/archive/html/bug-bash/2023-12/msg00055.html

But one of the wonderful things about free software is that it's right
there for you -- it doesn't disappear when a new release comes out.
You don't lose anything. That's "forever."

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature