[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: $((expr)) allows the hexadecimal constant "0x"
From:       Chet Ramey <chet.ramey () case ! edu>
Date:       2023-06-29 20:20:13
Message-ID: daf3ae7e-7b4f-e63f-5621-a78390007f9a () case ! edu
[Download RAW message or body]

On 6/29/23 1:28 PM, Martin D Kealey wrote:
> On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko <dvlasenk@redhat.com> wrote:
> 
>> IIRC bash used to allow numeric constants of the
>> BASE#DIGITS form even if the DIGITS part was empty.
>> IOW: not only "64#0", but "64#" too was accepted
>> as a valid zero constant.
>>
>> This no longer works in 5.2.15, probably better than
>> former behavior, "64#" looked quite confusing.
>>
> 
> Oh great :-(
> 
> This change will break scripts that use $((10#$somevar)) to cope with
> somevar having leading zeroes OR BEING EMPTY.

Or containing a unary plus or minus, which was the start of the discussion
that led to this clearly invalid syntax changing in the first place. 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


> Is there any chance this can be reversed before it becomes an official
> release?

This happened years ago.

> 
> 
>> 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.

-- 
``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/


[prev in list] [next in list] [prev in thread] [next in thread]