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-Thread: 103376,6339fea48a1b8cda X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!69.16.185.51.MISMATCH!tmp-post01.iad!news.highwinds-media.com!roadrunner.com!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Enumeration representation clause surprise. 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> <1c847838-26d7-4517-a010-1851aa12351a@m3g2000hsc.googlegroups.com> From: Keith Thompson Organization: None to speak of Date: Fri, 13 Jun 2008 10:52:43 -0700 Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:DKOJszfY1y3QJjyt0C18b5V1PtU= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 75.80.183.54 X-Complaints-To: abuse@rr.com Xref: g2news1.google.com comp.lang.ada:699 Date: 2008-06-13T10:52:43-07:00 List-Id: Mike Silva writes: > On Jun 13, 3:21�am, Keith Thompson wrote: >> Mike Silva writes: >> > On Jun 12, 2:41�pm, Markus Sch�pflin 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 to >> >> 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. �IANALL, 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. �And 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. >> > 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"? Oh, I see what you mean (I was missing your point). Hmm. Using a biased representation when the user has specified the exact representation via an enumeration representation clause seems clearly wrong. My thought was that a biased representation is perfectly ok if the user didn't specify the representation. The point I missed is that a biased representation is going to be used only if the user asked for something to be smaller than it would ordinarily be. So the question is, if I have something with range 100..101, and I use a record representation clause to request that it be stored in 1 bit, is it ok to use a biased representation, mapping 100 to 0 and 101 to 1? I think I'd still argue that it's ok, since I only specified one particular aspect of the representation, namely the number of bits. I didn't specify that 100 be represented as the bit sequence 1100100, and 101 as the bit sequence 1100101 (partly because there's no mechanism to specify that). If the compiler is able to generate code that gets the right answers *and* that satisfies those aspects of the representation that I specified, that's (at least arguably) ok. But I'd still say that a warning is appropriate, so that if I really do want an unbiased representation I can change the clause to allocate at least 7 bits. Using a biased representation in the presence of pragma Pack is perhaps another question. In that case, I've only specified minimal size, and deliberately refrained from specifying the details. But always warning about biased representations isn't a bad idea anyway. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"