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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6339fea48a1b8cda X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!m3g2000hsc.googlegroups.com!not-for-mail From: Mike Silva Newsgroups: comp.lang.ada Subject: Re: Enumeration representation clause surprise. Date: Fri, 13 Jun 2008 06:31:41 -0700 (PDT) Organization: http://groups.google.com Message-ID: <1c847838-26d7-4517-a010-1851aa12351a@m3g2000hsc.googlegroups.com> References: <0cbb6daf-01e9-40f5-855c-4f1d45cb0096@m73g2000hsh.googlegroups.com> <87abhs6qyj.fsf@willow.rfc1149.net> <55613982-679e-419d-8656-03b549393289@w4g2000prd.googlegroups.com> <871w346k4j.fsf@willow.rfc1149.net> <4a84770f-e273-41ad-a8ef-f22a9896b544@i36g2000prf.googlegroups.com> <48502e38$0$23821$4f793bc4@news.tdc.fi> <0d642988-cb65-412d-88b2-806e1a5b0ff3@34g2000hsh.googlegroups.com> <48516de5$0$7547$9b4e6d93@newsspool1.arcor-online.net> NNTP-Posting-Host: 71.51.178.124 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1213363901 27715 127.0.0.1 (13 Jun 2008 13:31:41 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 13 Jun 2008 13:31:41 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m3g2000hsc.googlegroups.com; posting-host=71.51.178.124; posting-account=QgO_5wkAAACZKtAvkb3f1VNDm9C58qLr User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:691 Date: 2008-06-13T06:31:41-07:00 List-Id: On Jun 13, 3:21=A0am, Keith Thompson wrote: > Mike Silva writes: > > On Jun 12, 2:41=A0pm, Markus Sch=F6pflin wrote: > >> Mike Silva schrieb: > [...] > >> > Are you saying now that there's no problem after all? > > >> Not at all. The memory layout of the variables is not what I expect it > >> to be, because the compiler silently biased those values. The compiler > >> is perfectly aware of this, as it makes up for the biasing when > >> explicitly querying the value, but this doesn't help at all because I'm= > >> interested in the exact bitwise representation. > > >> Admittedly, there is an inconsistency in what I'm asking the compiler t= o > >> do, but that's the whole point: I do not want this inconsistency to be > >> silently 'fixed' by the compiler, I want to get noted about my error to= > >> get a chance and fix it myself. > > > I wonder then if this is an error at all. =A0IANALL, but if the program > > makes available your specified values when queried with the proper > > mechanism (in this case, unchecked conversion), then I don't see what > > difference it makes how it stores the representations in raw memory. > > > I'd welcome other comments on the validity or non-validity of this > > view. > > If it doesn't make any difference how the representations are stored > in raw memory, then you wouldn't use a representation clause; you'd > let the compiler make any decisions about representation, subject to > the constraint that the code has to produce the right answers. > > But if you *do* provide a representation clause, then the > representation clearly *does* matter. =A0And if the compiler can't > satisfy the requested representation (e.g., because two representation > clauses contradict each other), then the compiler should reject the > compilation unit. >- Hide quoted text - > > - Show quoted text - So that's why I'm wondering why compiler writers ever introduced biased representations in the first place. I can't believe that the problem with this approach has only been noticed in 2008. Aren't biased representations fundamentally incompatible with "the representation clearly *does* matter"?