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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: OO, C++, and something much better! Date: 1997/01/10 Message-ID: #1/1 X-Deja-AN: 209140808 references: <32CCE4ED.6A21@online.no> <5ajo99$khu@panix.com> <32ce7009.280817694@news.zip.com.au> <32D0CA27.44C2@ghgcorp.com> <32D245D5.2C0@ghgcorp.com> organization: New York University newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-10T00:00:00+00:00 List-Id: Keith says "On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that do not make sense should raise Program_Error". The AARM (Annotated Ada Reference Manual) gives the examples of X < Y and conversions between Integer_Address and Address on a segmented architecture. (Note also that it's not necessary to use System.Storage_Elements; relational operators on type Address are provided in System.)" Nope, you are reading too much into the RM here. Also reading the AARM is always a risky business (remember it is just opinion, nothing more :-) Let's take the case of a segmented architecture. It is common for C compilers in such environments (Large mode on the 8086) to limit objects to 64K bytes and to compare ONLY the offset parts of the addresses so that address comparison onlly works when it is defined to work, and gives silent junk answers when used between different objects. One neither expects nor encounters Keith's supposed "reasonable" behavior where this is likely to work. If we look at the corresponding Ada case, I cannot see any justification whatsoever for not properly allowing conversoin of any possible segmented address to an integer address. Such an operation makes perfect sense in this environment and is therefore REQUIRED TO BE SUPPORTED! You are only allowed to raise PE for things that do not make sense. Since this machine has a well define notion of linear address, it is clear to me that (a) any implementor on this environment would provide the obvious conversion and (b) that if they did not, they could not seek refuge in the RM. Let's actually look at the AARM wording, it says, if we quote it in full, rather than paraphrase as Keith did: 16.a Discussion: For example, on a segmented architecture, X < Y might raise Program_Error if X and Y do not point at the same segment (assuming segments are unordered). Similarly, on a segmented architecture, the conversions between Integer_Address and Address might not make sense for some values, and so might raise Program_ Error. Why this "for some values", that's becuse the conversoin in the opposite direction from Integer_Address to Address is indeed problematical, and one might well decide to raise Program_Error for some values in this direction. Keith's point that there is a comparison operation on addresses directly is true, but it is not a good idea to use these operations, since it is indeed sensible to decide that certain comparisons are not meaningful when performed directly on segmented addresses. So, to summarize (and explain Alex's legitimate point), an implementation of data structures in Ada which converts Address values to Integer_Address and then compares the Integer_Address values will work on all likely architectures including segmented architectures, and is from a formal point of view defined to either work as expected or raise Program_Error. By contrast, if you compare addresses in a corresponding C program, the address comparison will in fact produce meaningless results silently in the case of segmented architectures, and from a formal point of view nothing at all can be said about the semantics of the comparison operation. *quite* a difference, and enough for Alex to decide quite reasonably, that a standard implementation of libraries for C++ (which has the same semantics as C here) could not legitimately use these undefined comparison operations, whereas in the Ada 95 case, they could reasonably used. Yes, in the Ada 95 case, one could perhaps imagine a machine in which there was no sensible linearization of addresses, but I certainly don't know of any such machine, so such considerations are of a purely theoretical nature. In the C case, many programmers have been burned by the "unexpected" behavior of address comparisons on a segmented machine. For example, if you have int p [10]; then ((p-1) < p) can be false, so a loop that works by pointing one before the array to initialize can fail. equally if you do something like (x = p; x < &p[10]; p += 3) you can find you have an infinite loop, all quite in accordance with the C semantics, although somewhat surprising.