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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,83d7c4caadb45100 X-Google-Attributes: gid103376,public From: adam@irvine.com (Adam Beneschan) Subject: Re: DECAda/VMS - calling GETJPI Date: 1996/06/05 Message-ID: <4p547s$n99@krusty.irvine.com> X-Deja-AN: 158690056 references: <4p183b$2vs@linus.mitre.org> <4p1v56$214@linus.mitre.org> organization: /z/news/newsctl/organization newsgroups: comp.lang.ada Date: 1996-06-05T00:00:00+00:00 List-Id: mfb@mbunix.mitre.org (Michael F Brenner) writes: > Robert Dewar replied: > >> That's quite wrong, the type conversoin checks that the value is in >> range, and the value is outside the range. Indeed if you add a constant >> to the declaration of integer_minus_1, the out of range condition will >> be detected at compile time by GNAT: >> 2. type ul is mod 2 ** 64; >> 3. integer_minus_1: constant integer := -1; >> 4. x: ul := ul (integer_minus_1); >> | >> >>> warning: static value out of range of type "ul" defined at line 2 >> >>> warning: "constraint_error" will be raised at runtime . . . > ------------ > Mike Brenner responded: > >> That's quite right, GNAT gives the error message below, but in doing >> so it violates the Ada 95 Reference Manual and Rationale. Specifically, >> (Rationale 3.3.2 fourth paragraph): The normal arithmetic operations >> apply [to modular types] ... overflow cannot occur. (3.3.2 fifth paragraph) >> Conversion from modular to signed integer types works in a useful manner >> so that overflow does not occur. (3.3.2 sixth paragraph) We can think >> of this conversion as being somewhat akin to the sliding of array >> conversions. (2.12) ... the removal of the notorious irritation that >> for I in -1..100 loop was not allowed in Ada 83. It is allowed in Ada 9X. >> (3.8) We have generalized implicit subtype conversions on arrays (sliding) >> to apply in more circumstances. These new rules should minimize the times >> when an unexpected constraint_error arises when the length of the array >> value is appropriate, but the upper and lower bounds do not match the >> applicable index constraint. ... the bounds may be freely readjusted to fit >> the context. (3.3.2 paragraph 2) The modular types are unsigned integer >> types which exhibit cyclic arithmetic. They thus correspond to the >> unsigned types of some other languages such as C. (RM 3.5.4(1)) A modular >> type is an integer type with all arithmetic modulo a specified positive >> modulus. Such a type corresponds to an unsigned type with wrap-around >> semantics. (RM 3.5.4(19)) For a modular type, if the result of >> the execution of a predefined operator (see 4.5) is outside the base >> range of the type, the result is reduced modulo the modulus of the type >> to a value that is within the base range of the type. For a signed integer >> type, the exception constraint_error is raised by the execution of an >> operation that cannot deliver the correct result because it is outside >> the base range of the type. For any integer type constraint_error is >> raised by the operators /, REM, and MOD if the right operand is zero. >> (RM 4.6(30)) Numeric Type Conversion: If the target and the operand types >> are both integer types, then the result is the value of the target type >> that corresponds to the same mathematical integer as the operand. . . . >Mike Brenner responds > >Six of the quotes came from the Rationale, three of the quotes came from the >RM, and there is no contradiction between the six and the three. The gnat >interpretation is an inefficient interpretation because it requires extra >checks and extra consternation on the part of maintenance and development >programmers. The gnat interpretation is an incorrect interpretation because >it does not comply with the Reference Manual 3.5.4(19) requiring reduction >modulo the modulus; it does not comply with the Reference Manual 3.5.4(1) >requiring ALL arithmetic to be modulo the modulus (including type casting); >it does not comply with Reference Manual 4.6(30) requiring type conversion >to go to the same mathematical integer, which according to Reference Manual >3.5.4(1) is modulo the modulus. Sorry, Mike, but 3.5.4(19) isn't relevant. 3.5.4(19) talks about the result of the execution of a predefined operator; and type conversion is not a predefined operator. See 4.5. 3.5.4(1) really doesn't apply either, since it says "all arithmetic [is] modulo a specified positive modulus." Type conversions really don't qualify as arithmetic, although I suppose that could be open to debate. The RM doesn't define the term "arithmetic". > >After going modulo the modulus, no number can be outside the range of a >modular type. > >Paragraph 28 of Section 4.6 states that constraint_error on conversion >. This is a typographical >error. It makes no sense, and it contradicts both the above three >paragraphs in the Reference Manual, and it contradicts the fact that >constraint_error is raised only on converting to a non-modular type. > >It should be changed to read non-modular type>. I'm not qualified to determine whether this is a typo. Actually, the only people that can say for sure are those involved in writing the RM. I'll have to admit that I don't know what the paragraph as written means. -- Adam