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: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: DECAda/VMS - calling GETJPI Date: 1996/06/04 Message-ID: <4p1v56$214@linus.mitre.org> X-Deja-AN: 158465702 references: <31B2AF74.668E@dial.eunet.ch> <4p183b$2vs@linus.mitre.org> organization: The MITRE Corporation, Bedford Mass. newsgroups: comp.lang.ada Date: 1996-06-04T00:00:00+00:00 List-Id: Mike Brenner said: "you could just assign it: integer_minus_1: integer := -1; x: unsigned_longword := unsigned_longword (integer_minus_1); because Ada 95 modular types truncate numbers to their modular range without giving a constraint_error." ------------ 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 > > Yes, you can apply the unary minus operator to an unsigned vaue and get > modular results as expected, but here the minus is applied to a signed > type and generates a real minus one, which is definitely outside the > range of any unsigned type. ------------ 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. ------------ Robert Dewar responded: It's probably time again to repost the plea that if you suggest a solution to a problem, compile an example and make sure it works. No one is realiable enough to be 100% accurate without such a backup check, and posting incorrect information on Ada can cause a lot of confusion! ------------ Mike Brenner responded: > I compiled my example before posting this, and reported it as a bug > in gnat, with an example. The fact that it fails in gnat does not mean > the solution is erroneous; the other possibility is that the gnat > interpretation of the Reference Manual and Rationale violates the > above sentences. Gnat's erroneous interpretation places us at risk of > creating another notorious irritation, another unexpected constraint_error, > a needless inefficiency, and a contradiction to the meaning of the words: > Modular, Cycle, Sliding, Reduced, Wrap-Around Semantics, Useful, and > Cannot Occur. > Recommendation: To avoid causing a lot of confusion, please change gnat > to comply with the above sentences from the Reference Manual and Rationale, > permitting modular, cyclical, reduced, wrap_around semantics to occur when > converting a signed integer to an unsigned integer, providing a Useful > operation where constraint_error does not occur. ------------ Robert Dewar responded: That's right GNAT violates the Rationale here. That's because the Rationale is wrong. TO be fair, the problem is that it reflects the language design as it was prior to the meeting in England. Mike, always read the RM, not the Rationale, when they disagree, the Ratoinale has no official status whatsoever. You cannot violate the Rationale really, since it is not an official document. You can disagree with it, and most certainly should, when the Rationale is incorrect. The RM is quite clear on this point (I notice you did not try to quote the RM to back up your incorrect interpretation, though it is certainly understandable that you would assume that what you read in the Rationale was correct). The conversion raises constraint error because the value in question is outside the range of the target type. Nowhere in the RM can you find a suggestion that modular types are treated specially in such conversions because there is no such special treatment. There are not many technical errors in the Rationale of this type. All the ones I know about are in this category, they reflect a change to the language made late on, where the Rationale did not track the change. It would be quite useful to have a comprehensive errata list for the Rationale, but I do not know of one. Anyway, bottom line, GNAT is right, Mike is wrong! P.S. for the RM archeologists, the most obvious reference is in section 4.6 28 For the evaluation of a type_conversion that is a value conversion, the operand is evaluated, and then the value of the operand is converted to a corresponding value of the target type, if any. If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised; this can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type. [seems clear enough to me!] ------------ 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. 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 . For example, when converting to type integer and the value is out of range of integer'first..integer'last, a constraint_error is generated. Since modular types must never give a constraint_error, and since non-modular types must always give a constraint_error when an out of range value is provided to a type converter, this typographical error should be corrected. Recommendation: Fix this typographical error through the proper channels, but in the meanwhile, change your interpretation of modular types back to that of the Rationale, change gnat to convert modular types without giving a constraint_error, and please give a reference to the meeting in England which overrides the Rationale and how I can participate in future meetings of this sort. Mike Brenner