bug-bash
[Top][All Lists]
Advanced

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

Re: Number with sign is read as octal despite a leading 10#


From: Isaac Marcos
Subject: Re: Number with sign is read as octal despite a leading 10#
Date: Tue, 10 Jul 2018 18:46:32 -0400

2018-07-10 18:12 GMT-04:00 Eduardo Bustamante <address@hidden>:

> On Tue, Jul 10, 2018 at 1:57 PM, Isaac Marcos
> <address@hidden> wrote:
> > Chet Ramey (<address@hidden>) wrote:
> [..]
> > This is not a serious argument.
> [...]
> > I don't care. All other shells do this correctly. It makes you the only
> one
> > wrong.
> >
> > This is not a serious discussion.
>
> Can you keep the discussion civil?


No.


> I don't get why you feel compelled
> to qualify an argument from the main developer as "non serious".
>

Because *he* qualified my comments as "non serious" in another email.


> What's your definition of "correct"?


Exactly what was posted on the fist post. That a `a=+0034; echo
"$((10#$a))"' print 34 not 28.

Try this(from some other e-mail I did send):

        set -- 34 034 0034 +34 +034 +0034 -34 -034 -0034 ;
        for i do printf '%6s' "$((10#$i))"; shift; done; echo


                34    34    34    34    28    28   -34   -28   -28     #
bash
                34    34    34    34    28    28   -34   -28   -28     #
posixbash
                34    34    34    34    34    34   -34   -34   -34     #
lksh
                34    34    34    34    34    34   -34   -34   -34     #
mksh
                34    34    34    34    34    34   -34   -34   -34     #
ksh93
                34    34    34    34    34    34   -34   -34   -34     #
attsh
                34    34    34    34    34    34   -34   -34   -34     # zsh

Only bash prints 28. Why others can print 34 ?

According to Chet, the definition
> is the same as the ISO C standard. I'm not sure if there's a public
> version of the ISO C standard document, but
> http://c0x.coding-guidelines.com/6.4.4.1.html seems to be good enough.
> The definition of an "integer constant" in that document does not
> include a sign.
>

That is a description of the inability (or unwillingness) to raise above c
limitations.

What is odd in expecting that an string like `-00133` actually mean `-133`
in decimal?

Even more if the shell is explicitly told to parse the string as decimal
with the `10#'.


> So, in that regard, Bash is behaving according to specification.
>

As is also according to specification (of c) that a string could not have a
NUL byte but
some shells raise above that limit and are able to reasonably use such
values.

But I don't care anymore. This is the way in which users are lost, and you
have lost me.

I'll just use some other shell.


-- 
Cases are always threesome:
Best case, Worst case, and Just in case


reply via email to

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