Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdahl!uunet!mcvax!cernvax!ethz!heiser From: heiser@ethz.UUCP (Gernot Heiser) Newsgroups: comp.lang.modula2 Subject: Re: type changes Message-ID: <475@ethz.UUCP> Date: 24 Jun 88 08:12:02 GMT References:Reply-To: heiser@iis.UUCP (Gernot Heiser) Organization: ETH Zuerich, Switzerland Lines: 55 In article Info-Modula2 Distribution List writes: > > Programmers frequently use expressions like INTEGER(c) > in order to convert a value of type CARDINAL into one of type > INTEGER. However, this practice ought to be avoided > since it only works if the types CARDINAL and INTEGER > have the same representation for the possible values of c. > Although this is likely to be the case, programmers ought to use > VAL(INTEGER,c) which is guaranteed to work for appropriate values of c. Sorry for having to contradict here: There is nothing in the report (as I read it) that supports the claim that VAL(INTEGER,c) or VAL(CARDINAL,i) will work "as intended" although it _does_ work on all compilers I know (at least all those that implement VAL more or less according to the report). In fact a strict interpretation of the report implies the opposite. Quoting from PIM2, ed3, p 162: "ORD(x) ordinal number (of type CARDINAL) of x in the set of values defined by type T of x. T is an enumeration type, CHAR, INTEGER, or CARDINAL. "VAL(T,x) the value with ordinal number x and with type T. T is any enumeration type, or CHAR, INTEGER, or CARDINAL. VAL(T,ORD(x)) = x, if x is of type T." In other words, VAL with a CARDINAL argument is the inverse of ORD. The question is, what is ORD(i) (i being INTEGER)? It cannot be the CARDINAL representation of the number whose INTEGER representation is i, since not all numbers that have an INTEGER representation have a CARDINAL representation too (namely the negative INTEGERs). So, unless one assumes that ORD is not defined for all INTEGERs (and there is no indication in the report that would support such an assumption) and unless one is prepared to treat INTEGER as a special case (different from enumerationes, CHAR and CARDINAL, and again there is no indication to support that in the report) one has to assume that ORD(MinInt)=0, ORD(MinInt+1) = 1, ORD(MaxInt)=MaxCard etc. Consequently, VAL(INTEGER,c) does not at all work as intended! (For all other types VAL(T,x) is indeed the "safe" conversion.) I agree, that's nonsensical, however that's what the report says. Fortunately, no compiler (that I know of) does it that way, but assuming VAL(INTEGER,c) to be the "safe" conversion from CARDINAL to INTEGER is relying on all compilers violating the language report. Note that Wirth in his later compilers solves the problem in his characteristic way: he gives VAL(T,x) the semantics that T(x) used to have and completely eliminates "save" type transfers. > == > Barry Cornelius -- Gernot Heiser Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%ifi.ethz.ch@relay.cs.net ETH Zuerich EARN/BITNET: GRIDFILE@CZHETH5A CH-8092 Zuerich, Switzerland EUNET/UUCP: {uunet,mcvax,...}!iis!heiser