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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!lupine!infopiz!athertn!hpda!hpwala!cfisun!ima!mirror!rayssd!raybed2!linus!mbunix!eachus From: eachus@mbunix.mitre.org (Robert Eachus) Newsgroups: comp.lang.ada Subject: Re: Implicit conversion? Summary: It is legal Keywords: 13.6 Message-ID: <46125@linus.UUCP> Date: 8 Mar 89 16:38:46 GMT References: <5678@sdcrdcf.sm.unisys.com> Sender: news@linus.UUCP Reply-To: eachus@mbunix.mitre.org (Robert I. Eachus) Organization: The MITRE Corporation, Bedford, Mass. List-Id: In article <5678@sdcrdcf.sm.unisys.com> steve@sm.unisys.com (Steven Holtsberg) writes: > >In the following program, some implicit type conversion apparently >takes place. However, looking at the Standard, I cannot see where >this should happen. ... >with SYSTEM; use SYSTEM; > >procedure example is > x: tiny_integer; >begin > x:= MAX_INT - MAX_INT; >end example; >With the Verdix xompiler, this program compiles and executes normally, >so, there is apparently a convertion of 0 to TINY_INTEGER. No, there is an implicit conversion of MAX_INT to tiny_integer. >"An implicit conversion of an operand of type universal_integer >to another integer type...can only be applied if the operand is >either a numeric literal, a named number, or an attribute; such >an operand is called a convertible universal operand in this section. >An implicit conversion of a convertible universal operand is applied >if and only if the innermost complete context (see 8.7) determines >a unique (numeric) target type for the implicit conversion, and there >is no legal interpretation of this context without this conversion." >From 8.7, the innermost complete context of SYSTEM.MAX_INT in the above >example is the assignment statement > x := MAX_INT - MAX_INT; -- corrected per following message... True, and this complete context determines that the unique target type for the conversion is tiny_integer. If there were a visible declaration: "function "-" (L,R: Integer) return tiny_integer" then the implicit conversions would be illegal. >What the Verdix compiler is apparently doing is figuring out that >MAX_INT - MAX_INT is zero (at compile-time)... True, but it is not converting the result to zero, it is using the "-" operator for tiny_integer and doing the conversion first. This is legal, and must be legal, on all implementations. However, it may raise an exception during execution. The reason Verdix doesn't raise CONSTRAINT_ERROR or NUMERIC_ERROR is more subtile. If you look at 3.5.5(1) you find that implicit conversion to an integer type is a basic operation of the type. In 11.6(3) (but read all of 11.6) "...freedom is left to an implementation for reordering actions...that are...basic operations other than assignments. This freedom is left, as defined below, even where the execution...may propagate a predefined exception." The note in 11.6(9) makes it perfectly clear that execptions need not be raised for implicit conversions from universal types. As for the subtraction, 4.5(7) says: "A predefined operation that delivers a result of an integer type (other than universal_integer) can only raise the exception NUMERIC_ERROR if the mathematical result is not a value of the type." Zero is a value of tiny_integer, so the subtraction can not raise an exception. >At I right, or am I wrong? Wrong, but the language may be wrong too. AI-315, which has not yet been approved, discusses the fact that 11.6 may give too much rope to clever compilers. When we figure out a rule that does not inhibit useful optimizations like constant folding, but allows a user to insure that certain out-of-range expressions always raise an exception, the rules may change. Robert I. Eachus with STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...