From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,60fe876e7675f11 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.189.72 with SMTP id gg8mr14741554pbc.4.1328638635275; Tue, 07 Feb 2012 10:17:15 -0800 (PST) Path: lh20ni271329pbb.0!nntp.google.com!news2.google.com!postnews.google.com!h6g2000yqk.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Weird behavior with modular type Date: Tue, 7 Feb 2012 10:15:27 -0800 (PST) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1328638635 4467 127.0.0.1 (7 Feb 2012 18:17:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 7 Feb 2012 18:17:15 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h6g2000yqk.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-02-07T10:15:27-08:00 List-Id: On Feb 7, 9:24 am, Yannick Duch=EAne (Hibou57) wrote: > Hi all, > > I expect the test to be shortened enough. > > The following compiles and run without an error: > > with Ada.Text_IO; > procedure Bug is > > type Modular_Type is mod 256; > subtype Index_Type is Natural range 1 .. 3; > > E : Modular_Type :=3D 255; > I : Index_Type :=3D 3; > B : Boolean; > > begin > B :=3D E < 10 ** I; > Ada.Text_IO.Put_Line (Boolean'Image (B)); > end Bug; > > It prints "FALSE" > > Now, the following, with added "Natural'Pos (...)", did not even compile: > > with Ada.Text_IO; > procedure Bug is > > type Modular_Type is mod 256; > subtype Index_Type is Natural range 1 .. 3; > > E : Modular_Type :=3D 255; > I : Index_Type :=3D 3; > B : Boolean; > > begin > B :=3D E < Natural'Pos (10 ** I); > Ada.Text_IO.Put_Line (Boolean'Image (B)); > end Bug; > > That's counter intuitive. I would expect the first to behave as the > second, with either a failure to compile or range error at run-time. > > Someone remember a pointer to the most relevant part in the RM? I may be = a > bit tired, could not find it. > > Seems in the first case, the left-side of "E < 10 ** I" has a modulo > applied, or else, I see no way to explain the result, "FALSE". But why > would this modulo be applied with a subtype of Natural and not with an > Universal_Integer? > > I don't like it (and must be idiot in some way, don't you think?). I think my first attempt to respond may have failed... retrying... In the first example, "**" is a function whose left operand is the modular type Modular_Type, and whose right operand has type Integer (actually Integer'Base). Unlike most other binary operators, whose two operands are of the same type, "**" always has a right operand of type Integer [and sometimes subtype Natural], regardless of the type of the left operand. Perhaps that's what's confusing you? Anyway, this means that in 10**I, the type of 10 is the modular type Modular_Type, which means that "**" is a modular operation, which wraps around. In the second example, the left operand of "**" has type Integer, because of the Natural'Pos which means that the expression inside parentheses has to be of type Integer (subtype Natural). Thus, the value of Natural'Pos (10**I) is 1024--this operation doesn't wrap around. And to use this value as an operand to "<", it has to be converted to type Modular_Type, which will get a Constraint_Error because 1024 is out of range of the modular type. (Type conversions don't automatically wrap.) So this program, unlike the first, should get a Constraint_Error. It should compile, though; it appears to be a compiler bug that it didn't compile. -- Adam