From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_40 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
X-Received: by 2002:ac8:2a8f:: with SMTP id b15mr18329487qta.33.1608593123443;
        Mon, 21 Dec 2020 15:25:23 -0800 (PST)
X-Received: by 2002:ad4:4c8c:: with SMTP id bs12mr19829267qvb.11.1608593123339;
 Mon, 21 Dec 2020 15:25:23 -0800 (PST)
Path: eternal-september.org!reader02.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 21 Dec 2020 15:25:23 -0800 (PST)
In-Reply-To: <064ea324-7f68-4405-a733-3e37e51b9950n@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=107.88.177.42; posting-account=JSxOkAoAAADa00TJoz2WZ_46XrZCdXeS
NNTP-Posting-Host: 107.88.177.42
References: <75fbea31-93f7-4b0d-bd73-34c4beefff44n@googlegroups.com> <064ea324-7f68-4405-a733-3e37e51b9950n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e9ed12c5-9254-4d44-823e-a2f3f8da16aan@googlegroups.com>
Subject: Re: Help parsing the language manual on Get'ing integers from Strings
From: John Perry <john.perry@usm.edu>
Injection-Date: Mon, 21 Dec 2020 23:25:23 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader02.eternal-september.org comp.lang.ada:60917
List-Id: <comp.lang.ada>

AdaCore replies:

> Thanks for your report.  We believe the intent of the RM is that
arbitrary lookahead/backtracking should not be required, so GNAT raises
an exception when it encounters something wrong (like a base > 16).  We
believe no Ada compilers are in strict conformance to the rules in this
area, and ARG has agreed not to test this area strictly.  Perhaps
RM-A.10.8(8) should be clarified/corrected.

> The rule about colons is hidden away in RM-J.2(3). But this isn't
specific to colons -- you'd get the same behavior if you used "#"
instead.

Sure enough, the string "29# " leads to a data error. If I read this right, the problem is that the compiler sees it as base 29, which Niklas Holsti had hinted at, but I didn't quite follow the implications.

So, not a bug!

john perry