Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Isaac Marcos <isaacmarcos100010@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Number with sign is read as octal despite a leading 10#
Date: Sun, 12 Aug 2018 03:37:31 -0400
Lines: 92
Approved: bug-bash@gnu.org
Message-ID: <mailman.5026.1534059477.1292.bug-bash@gnu.org>
References: <CA+n9pTy7vSPUA0j-bDF9_eWF0XysePRDAFckgvvHX8haSWv7KQ@mail.gmail.com> <c8ae5df2-b6b3-438f-bd99-4618f6b2d3c0@Spark> <71850c03-54d3-6a7e-1d29-136950d9e139@iki.fi> <a0b100e7-3e14-e56e-8ffb-fcaeca587bf1@case.edu> <CA+n9pTwOZNdmWqEYwE5cDohArgvZ285vSt-F=hw=ZGb8weO2qA@mail.gmail.com> <471822f3-4484-59b5-0433-fc394dc9b34a@case.edu> <CA+n9pTzNU4stJykWKAJkPzwwrkmxzirWmuUT_xA9U=ZWsh3nMQ@mail.gmail.com> <CAOSMAutyKDe7QqVHLQ_jFBzZ09hiOwz_LfkoCVYXpDGVNohm0Q@mail.gmail.com> <CA+n9pTxfKTmmqPabZ+XMqk4PPhiX4x_yQy-W6TnyndR3iBO-HA@mail.gmail.com> <709908e4-693e-3d91-3920-e91843c13f9d@case.edu>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: bug-bash <bug-bash@gnu.org>, bash@packages.debian.org
To: Chet Ramey <chet.ramey@case.edu>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <709908e4-693e-3d91-3920-e91843c13f9d@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:14468

Chet Ramey (<chet.ramey@case.edu <mailto:chet.ramey@case.edu>>) wrote:
> It doesn't matter. Unary plus and minus are operators, not part of
integer
constants.

But you are confused, what is after the 10# is not an integer constant, it
is an string.

An string that is being parsed by bash C code and coerced into a sign
operator and a string of digits.

What causes the problem is that the sign breaks the effect of the 10#.

But that is entirely the result of the chosen interpretation of the string.

You claim that it should be as the c language does it.
But that is in conflict with any common human interpretation, namely:

A number is:
An optional sign followed by one or more digits.

If you don't want to agree then mark this bug as wont-fix.

El mar., 10 jul. 2018 a las 23:31, Chet Ramey (<chet.ramey@case.edu>)
escribi=C3=B3:

> On 7/10/18 6:46 PM, Isaac Marcos wrote:
> > 2018-07-10 18:12 GMT-04:00 Eduardo Bustamante <dualbus@gmail.com
> > <mailto:dualbus@gmail.com>>:
> >
> >     On Tue, Jul 10, 2018 at 1:57 PM, Isaac Marcos
> >     <isaacmarcos100010@gmail.com <mailto:isaacmarcos100010@gmail.com>>
> wrote:
> >     > Chet Ramey (<chet.ramey@case.edu <mailto:chet.ramey@case.edu>>)
> wrote:
> >     [..]
> >     > This is not a serious argument.
> >     [...]
> >     > I don't care. All other shells do this correctly. It makes you th=
e
> 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.
>
> I did. You wrote:
>
> "Are you saying that bash should reject the use of negative numbers?
> And, If so, why bash does not raise an error? (as it is expected that it
> must do on invalid input)."
>
> This is clearly a ridiculous strawman.
>
> The topic is whether or not a sign can appear in the middle of an integer
> constant, even when that integer constant begins with the `base#' syntax.
>
> > Only bash prints 28. Why others can print 34 ?
>
> They extend the definition of an integer constant. It's perfectly
> reasonable to do that. Bash sticks to the C definition.
>
> >
> > What is odd in expecting that an string like `-00133` actually mean
> `-133`
> > in decimal?
>
> Why would that be reasonable? Integers beginning with `0' are octal
> constants.
>
>
> --
> ``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/
>


--=20
Cases are always threesome:
Best case, Worst case, and Just in case