Re: Enumeration representation clause surprise.

[Keith Thompson <kst-u@mib.org>]

Mike Silva <snarflemike@yahoo.com> writes:
> On Jun 13, 3:21�am, Keith Thompson <ks...@mib.org> wrote:
>> Mike Silva <snarflem...@yahoo.com> writes:
>> > On Jun 12, 2:41�pm, Markus Sch�pflin <nos...@nospam.org> 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  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"