Enumeration representation clause surprise.

Enumeration representation clause surprise.

[Markus Schoepflin]

Hello,

please consider the following code snippet:

    type ENUM_T is (ONE, TWO);
    for ENUM_T use (ONE => 1, TWO => 2);

    type RECORD_T is record
       A1 : ENUM_T;
       A2 : ENUM_T;
    end record;
    for RECORD_T use record
       A1 at 0 range 0 .. 0; -- (*)
       A2 at 1 range 0 .. 7;
    end record;
    for RECORD_T'Size use 2 * 8;

    FOO : RECORD_T;

I was _very_ surprised to discover that when executing

    FOO.A1 := TWO;
    FOO.A2 := TWO;

the binary content of FOO looks like this:

    00000010 00000001

IOW, for A1 ONE is coded as 0 and TWO as 1, and for A2 ONE is coded as 1 
and TWO as 2.

I checked this with GNAT 3.4.5 and some old DEC Ada compiler, therefore I 
think this behaviour is compiler independent.

Anybody knows why the compiler is allowed to silently ignore my 
representation clause for the enumeration? I would have expected to get an 
error at the indicated line, telling me that A1 is too small.

BTW, this was found in a real word application, where code like this was 
used to model a given external interface, and later the enumeration was 
extended by a few values, but the record representation clause was never 
updated.

Is there a way I can protect myself from this very nasty trap?

Best regards,
Markus

Re: Enumeration representation clause surprise.

[christoph.grein]

What you request for A1 seems impossible: Store value 2 = 2#01# in one
bit.

An illustrating example:

type My_Int is range 10_000 .. 10_001;

type My_Record is record
  I: My_Int;
end record;

for My_Record use record
  I at 0 range 0 .. 0;
end record;

This is allowed. My_Record holds only two values, so one bit is
enough. The compiler uses a so-called biased representation with
10_000 as bias, which need not be stored.

Hope this helps.

Re: Enumeration representation clause surprise.

[Markus Schoepflin]

christoph.grein@eurocopter.com wrote:

> What you request for A1 seems impossible: Store value 2 = 2#01# in one
> bit.

This is exactly my point. I would have expected a compile time error for 
this impossible request.

Representation clauses are (amongst other) meant to specify specific binary 
layouts for interfacing with the external world. Or am I mistaken here?

> An illustrating example:
> 
> type My_Int is range 10_000 .. 10_001;
> 
> type My_Record is record
>   I: My_Int;
> end record;
> 
> for My_Record use record
>   I at 0 range 0 .. 0;
> end record;
> 
> This is allowed. My_Record holds only two values, so one bit is
> enough. The compiler uses a so-called biased representation with
> 10_000 as bias, which need not be stored.

Yes, I am aware that this feature exists, I am just unhappy that it is also 
allowed for enumerations.

Is there another Ada mechanism for specifying external interfaces like this 
one? One that does not have the same subtle maintenance trap?

> Hope this helps.

Thanks,
Markus

Re: Enumeration representation clause surprise.

[christoph.grein]

Hm, I gather you have detected a nice way to shoot yourself in the
foot :-)

Re: Enumeration representation clause surprise.

[Samuel Tardieu]

Markus> This is exactly my point. I would have expected a compile time error
Markus> for this impossible request.

Markus> Representation clauses are (amongst other) meant to specify specific
Markus> binary layouts for interfacing with the external world. Or am I
Markus> mistaken here?

I can't find anything in RM chapter 13 which either forbids or allows
such a behaviour. I will submit a patch for GNAT which gives a new
warning for this case:

    11.       A1 at 0 range 0 .. 0; -- (*)
                 |
        >>> warning: component representation will be biased

  Sam

Re: Enumeration representation clause surprise.

[Markus Schoepflin]

Samuel Tardieu wrote:

> Markus> This is exactly my point. I would have expected a compile time error
> Markus> for this impossible request.
> 
> Markus> Representation clauses are (amongst other) meant to specify specific
> Markus> binary layouts for interfacing with the external world. Or am I
> Markus> mistaken here?
> 
> I can't find anything in RM chapter 13 which either forbids or allows
> such a behaviour. I will submit a patch for GNAT which gives a new
> warning for this case:
> 
>     11.       A1 at 0 range 0 .. 0; -- (*)
>                  |
>         >>> warning: component representation will be biased
> 
>   Sam

That would be extremely helpful!

Thanks,
Markus

Re: Enumeration representation clause surprise.

[Samuel Tardieu]

Sam> I will submit a patch for GNAT which gives a new warning for this
Sam> case

Markus> That would be extremely helpful!

Done, at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00680.html

Re: Enumeration representation clause surprise.

[Adam Beneschan]

On Jun 11, 6:28 am, Samuel Tardieu <s...@rfc1149.net> wrote:
> Markus> This is exactly my point. I would have expected a compile time error
> Markus> for this impossible request.
>
> Markus> Representation clauses are (amongst other) meant to specify specific
> Markus> binary layouts for interfacing with the external world. Or am I
> Markus> mistaken here?
>
> I can't find anything in RM chapter 13 which either forbids or allows
> such a behaviour. I will submit a patch for GNAT which gives a new
> warning for this case:
>
>     11.       A1 at 0 range 0 .. 0; -- (*)
>                  |
>         >>> warning: component representation will be biased

This seems odd to me.  Having GNAT select a biased component in
Christoph's example makes some sense, since a compiler can choose any
representation it likes.  But in Markus' case, he specifically asked
for a certain representation for the enumeration types---should GNAT
take it upon itself to change that, and display a warning that doesn't
make it clear that it's disrespecting his request to have the
enumeration represented a certain way?

I dunno... maybe this would be acceptable to some, and apparently
Markus thinks it's OK, but ... it's just not what I would expect ...
I guess it's a subjective thing.

                                -- Adam

Re: Enumeration representation clause surprise.

[Markus Schoepflin]

Adam Beneschan wrote:
> On Jun 11, 6:28 am, Samuel Tardieu <s...@rfc1149.net> wrote:
>> Markus> This is exactly my point. I would have expected a compile time error
>> Markus> for this impossible request.
>>
>> Markus> Representation clauses are (amongst other) meant to specify specific
>> Markus> binary layouts for interfacing with the external world. Or am I
>> Markus> mistaken here?
>>
>> I can't find anything in RM chapter 13 which either forbids or allows
>> such a behaviour. I will submit a patch for GNAT which gives a new
>> warning for this case:
>>
>>     11.       A1 at 0 range 0 .. 0; -- (*)
>>                  |
>>         >>> warning: component representation will be biased
> 
> This seems odd to me.  Having GNAT select a biased component in
> Christoph's example makes some sense, since a compiler can choose any
> representation it likes.  But in Markus' case, he specifically asked
> for a certain representation for the enumeration types---should GNAT
> take it upon itself to change that, and display a warning that doesn't
> make it clear that it's disrespecting his request to have the
> enumeration represented a certain way?

Do you suggest to reword the warning? Or give an error instead?

> 
> I dunno... maybe this would be acceptable to some, and apparently
> Markus thinks it's OK, but ... it's just not what I would expect ...
> I guess it's a subjective thing.

Actually I'm OK with anything that gives me a way to detect this, be it 
warning, error, or whatever.

Markus

Re: Enumeration representation clause surprise.

[Samuel Tardieu]

Adam> This seems odd to me.  Having GNAT select a biased component in
Adam> Christoph's example makes some sense, since a compiler can choose any
Adam> representation it likes.  But in Markus' case, he specifically asked
Adam> for a certain representation for the enumeration types---should GNAT
Adam> take it upon itself to change that, and display a warning that doesn't
Adam> make it clear that it's disrespecting his request to have the
Adam> enumeration represented a certain way?
Adam> 
Adam> I dunno... maybe this would be acceptable to some, and apparently
Adam> Markus thinks it's OK, but ... it's just not what I would expect ...
Adam> I guess it's a subjective thing.

I would prefer an error indeed, but I can't seem to find a clause in
chapter 13 which says that in records with representation clauses the
representation given for objects when created independently the
enumeration representation clause must be honored.

Anyway, the patch I submitted will probably be evaluated by AdaCore
language lawyers. If an error must be signalled, then the warning will
be transformed into one.

  Sam

Re: Enumeration representation clause surprise.

[Adam Beneschan]

On Jun 11, 8:56 am, Samuel Tardieu <s...@rfc1149.net> wrote:
> Adam> This seems odd to me.  Having GNAT select a biased component in
> Adam> Christoph's example makes some sense, since a compiler can choose any
> Adam> representation it likes.  But in Markus' case, he specifically asked
> Adam> for a certain representation for the enumeration types---should GNAT
> Adam> take it upon itself to change that, and display a warning that doesn't
> Adam> make it clear that it's disrespecting his request to have the
> Adam> enumeration represented a certain way?
> Adam>
> Adam> I dunno... maybe this would be acceptable to some, and apparently
> Adam> Markus thinks it's OK, but ... it's just not what I would expect ...
> Adam> I guess it's a subjective thing.
>
> I would prefer an error indeed,

Then there's no reason it couldn't generate one... implementations are
allowed to reject any representation clauses (including component
clauses) that they don't support, and there's nothing in the
Implementation Advice of 13.5.1 that would "require" (or advise) an
implementation to support this.  (In fact, there's nothing that would
"require" an implementation to implement biased values as in
Christopher's example.)


> but I can't seem to find a clause in
> chapter 13 which says that in records with representation clauses the
> representation given for objects when created independently the
> enumeration representation clause must be honored.

Technically, that may be correct, although technically it may be that
the RM doesn't require the specified representation to be honored for
*any* objects, stand-alone or component.  At least I couldn't find
anything specific, unless this is "generally implied" by the whole
chapter or by 13.1.  It may be that it's legal for an implementation
to accept an enumeration representation clause and then never apply
it.  But components are objects, and I don't see anything in 13.4 that
would apply unequally to component objects vis-a-vis stand-alone
objects.

Anyway, since it's clearly legal for an implementation to reject
Markus' code, I think it should.  Although it may be *possible* that
an implementation *could* find a way to obey the record rep clause by
using a different representation for the enumeration component (if
this is indeed legal), there's a 0% chance that any such usage would
be what the programmer intended, and a 100% chance that a usage like
this would indicate an error on the programmer's part.

                                   -- Adam

Re: Enumeration representation clause surprise.

[Niklas Holsti]

Adam Beneschan wrote:

> ... technically it may be that
> the RM doesn't require the specified representation to be honored for
> *any* objects, stand-alone or component.  At least I couldn't find
> anything specific, unless this is "generally implied" by the whole
> chapter or by 13.1.  It may be that it's legal for an implementation
> to accept an enumeration representation clause and then never apply
> it.

There's a "Note" in RM13.4(11/1) that says "Unchecked_Conversion 
may be used to query the internal codes used for an enumeration 
type". I don't know if "Notes" are normative parts of the standard. 
It would be interesting to know what Unchecked_Conversion gives for 
the 1-bit record component in Markus' problematic record. If it 
gives 0 and 1, as encoded, and not 1 and 2, as required in the 
enumeration representation clause, it would seem to violate this 
"Note".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Enumeration representation clause surprise.

[tmoran]

>There's a "Note" in RM13.4(11/1) that says "Unchecked_Conversion
>may be used to query the internal codes used for an enumeration type".
   That, along with 13.4(7) "An enumeration representation clause
specifies the coding aspect of representation.  The coding consists of the
internal code for each enumeration literal, ..."  sure sounds to me like
an Unchecked_Conversion should return the internal code set by the
enumeration representation clause, ie, the number 1 or number 2 in this
case.  The fact the variable in question is in a record shouldn't make
that false.
  RM 13.1(1) says about representation items (a superset of representation
clauses) that "They can be provided to ...  or to interface with features
that are outside the domain of the language (for example, peripheral
hardware)."  In this case that clearly would not work.  And if the
compiler is going to ignore something the programmer asked for, it ought
to at least generate a warning.

Re: Enumeration representation clause surprise.

[Randy Brukardt]

"Markus Schoepflin" <nospam@no.spam> wrote in message 
news:g2oqld$qli$1@nntp.ilk.net...
> Adam Beneschan wrote:
>> On Jun 11, 6:28 am, Samuel Tardieu <s...@rfc1149.net> wrote:
>>> Markus> This is exactly my point. I would have expected a compile time 
>>> error
>>> Markus> for this impossible request.
>>>
>>> Markus> Representation clauses are (amongst other) meant to specify 
>>> specific
>>> Markus> binary layouts for interfacing with the external world. Or am I
>>> Markus> mistaken here?
>>>
>>> I can't find anything in RM chapter 13 which either forbids or allows
>>> such a behaviour. I will submit a patch for GNAT which gives a new
>>> warning for this case:
>>>
>>>     11.       A1 at 0 range 0 .. 0; -- (*)
>>>                  |
>>>         >>> warning: component representation will be biased
>>
>> This seems odd to me.  Having GNAT select a biased component in
>> Christoph's example makes some sense, since a compiler can choose any
>> representation it likes.  But in Markus' case, he specifically asked
>> for a certain representation for the enumeration types---should GNAT
>> take it upon itself to change that, and display a warning that doesn't
>> make it clear that it's disrespecting his request to have the
>> enumeration represented a certain way?
>
> Do you suggest to reword the warning? Or give an error instead?

I agree with Adam (whose message I mysteriously didn't receive). Even if the 
letter of the RM allows this sort of behavior, it seems wrong from an 
expectation basis: an explicitly given representation clause is being 
ignored where there is a conflict between two of them. That's never a good 
thing. So I think this should be an error - a compiler shouldn't be changing 
explicitly given representation items. (I realize that this may not be a 
generally held opinion.)

For the record, Janus/Ada gives:

In File D:\Testing\Win\console\rep.ada at line 11
--------------
   10:      for RECORD_T use record
   11:         A1 at 0 range 0 .. 0; -- (*)
----------------------------------^
*ERROR* More bits are needed to store all values of the type (6.4.17) [RM 
13.5.1(19)]
Continue <Sp> or Abort <^C>?

for this example. But that's not all that interesting, because Janus/Ada 
doesn't support biased representations.

                                 Randy.

Re: Enumeration representation clause surprise.

[Randy Brukardt]

"Markus Schoepflin" <nospam@no.spam> wrote in message 
news:g2oqld$qli$1@nntp.ilk.net...
> Adam Beneschan wrote:
>> On Jun 11, 6:28 am, Samuel Tardieu <s...@rfc1149.net> wrote:
>>> Markus> This is exactly my point. I would have expected a compile time 
>>> error
>>> Markus> for this impossible request.
>>>
>>> Markus> Representation clauses are (amongst other) meant to specify 
>>> specific
>>> Markus> binary layouts for interfacing with the external world. Or am I
>>> Markus> mistaken here?
>>>
>>> I can't find anything in RM chapter 13 which either forbids or allows
>>> such a behaviour. I will submit a patch for GNAT which gives a new
>>> warning for this case:
>>>
>>>     11.       A1 at 0 range 0 .. 0; -- (*)
>>>                  |
>>>         >>> warning: component representation will be biased
>>
>> This seems odd to me.  Having GNAT select a biased component in
>> Christoph's example makes some sense, since a compiler can choose any
>> representation it likes.  But in Markus' case, he specifically asked
>> for a certain representation for the enumeration types---should GNAT
>> take it upon itself to change that, and display a warning that doesn't
>> make it clear that it's disrespecting his request to have the
>> enumeration represented a certain way?
>
> Do you suggest to reword the warning? Or give an error instead?

I agree with Adam (whose message I mysteriously didn't receive). Even if the 
letter of the RM allows this sort of behavior, it seems wrong from an 
expectation basis: an explicitly given representation clause is being 
ignored where there is a conflict between two of them. That's never a good 
thing. So I think this should be an error - a compiler shouldn't be changing 
explicitly given representation items. (I realize that this may not be a 
generally held opinion.)

For the record, Janus/Ada gives:

In File D:\Testing\Win\console\rep.ada at line 11
--------------
   10:      for RECORD_T use record
   11:         A1 at 0 range 0 .. 0; -- (*)
----------------------------------^
*ERROR* More bits are needed to store all values of the type (6.4.17) [RM 
13.5.1(19)]
Continue <Sp> or Abort <^C>?

for this example. But that's not all that interesting, because Janus/Ada 
doesn't support biased representations.

                                 Randy.

Re: Enumeration representation clause surprise.

[christoph.grein]

On 12 Jun., 03:16, tmo...@acm.org wrote:
> >There's a "Note" in RM13.4(11/1) that says "Unchecked_Conversion
> >may be used to query the internal codes used for an enumeration type".
>
Tom wrote:

>    That, along with 13.4(7) "An enumeration representation clause
> specifies the coding aspect of representation.  The coding consists of the
> internal code for each enumeration literal, ..."  sure sounds to me like
> an Unchecked_Conversion should return the internal code set by the
> enumeration representation clause, ie, the number 1 or number 2 in this
> case.  The fact the variable in question is in a record shouldn't make
> that false.

This is a non sequitur.

type My_Record is record
  I: My_Int;
end record;

for My_Record use record
  I at 0 range 0 .. 0;
end record;

Also in this case an Unchecked_Conversion gives different results for
I declared as a record component or by itself.

But I support the other reasons why the actual aspect clause should
possibly be rejected.

Re: Enumeration representation clause surprise.

[Markus Schoepflin]

Niklas Holsti wrote:
> Adam Beneschan wrote:
> 
>> ... technically it may be that
>> the RM doesn't require the specified representation to be honored for
>> *any* objects, stand-alone or component.  At least I couldn't find
>> anything specific, unless this is "generally implied" by the whole
>> chapter or by 13.1.  It may be that it's legal for an implementation
>> to accept an enumeration representation clause and then never apply
>> it.
> 
> There's a "Note" in RM13.4(11/1) that says "Unchecked_Conversion may be 
> used to query the internal codes used for an enumeration type". I don't 
> know if "Notes" are normative parts of the standard. It would be 
> interesting to know what Unchecked_Conversion gives for the 1-bit record 
> component in Markus' problematic record. If it gives 0 and 1, as 
> encoded, and not 1 and 2, as required in the enumeration representation 
> clause, it would seem to violate this "Note".

Both GNAT and Dec Ada return 1 and 2 for both A1 and A2, so they are 
correctly debiasing when explicitly asked for the internal representation.

Markus

Re: Enumeration representation clause surprise.

[Mike Silva]

On Jun 12, 4:45 am, Markus Schoepflin <nos...@no.spam> wrote:
>
> Both GNAT and Dec Ada return 1 and 2 for both A1 and A2, so they are
> correctly debiasing when explicitly asked for the internal representation.
>
> Markus

Now I'm really confused.  In your OP you showed some "incorrect"
binary values - how did you get those values?  By inspecting memory?

Now you talk about explicitly asking for the internal representation.
What does that mean exactly?

Are you saying now that there's no problem after all?

Mike

Re: Enumeration representation clause surprise.

[Markus Schöpflin]

Mike Silva schrieb:
> On Jun 12, 4:45 am, Markus Schoepflin <nos...@no.spam> wrote:
>> Both GNAT and Dec Ada return 1 and 2 for both A1 and A2, so they are
>> correctly debiasing when explicitly asked for the internal representation.
>>
>> Markus
> 
> Now I'm really confused.  In your OP you showed some "incorrect"
> binary values - how did you get those values?  By inspecting memory?

Yes.

> Now you talk about explicitly asking for the internal representation.
> What does that mean exactly?

Using unchecked conversion to ask for the value of the variables.

> 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.

> Mike

Regards,
Markus

Re: Enumeration representation clause surprise.

[richtmyer]

On Jun 11, 7:38 am, Markus Schoepflin <nos...@no.spam> wrote:
> Hello,
>
> please consider the following code snippet:

etc

-----
Interesting. I had been playing with a similar example, and have
modified it a bit
to present. What got me is the record type with length 1 but an object
with that
type that was length zero! (It compiles without any warnings).

------------------------------ test1.2.ada
--------------------------------------
--
-- GPS 4.2.1 (20080115) hosted on pentium-mingw32msv
-- GNAT GPL 2007 (20070405-41)
--
--  X_Type'size     =  31
--  X_Rec_Type'size =  32
--  X_Rec'size      =  32
--  Y_Rec_Type'size =  1
--  Y_Rec'size      =  8
--  X_Rec.X1        =  2147483647
--  Y_Rec.X1        =  2147483647

--  GPS Pro 4.1.1 (20070423) hosted on i686-pc-linux-gnu
--  GNAT Pro 6.1.1 (20080111-41)
--
--  X_Type'size     =  31
--  X_Rec_Type'size =  32
--  X_Rec'size      =  32
--  Y_Rec_Type'size =  1
--  Y_Rec'size      =  0             -- this object is smaller than
its type!
--  X_Rec.X1        =  2147483647
--  Y_Rec.X1        =  2147483647

-------------------------------------------------------------------------

with ada.exceptions;  use ada.exceptions;
with interfaces.c;
with text_io;   use text_io;
with unchecked_conversion;

procedure test1 is

   type X_Type is ( X );
   for x_type use (x => 16#7FFF_FFFF#);

   type X_Rec_Type is
      Record
        X1 : X_Type;
      End Record;

   X_Rec : X_Rec_Type := (X1 => x);

   type Y_Rec_Type is
      Record
        X1 : X_Type;
      End Record;
   for Y_Rec_Type'size use 0;

   for Y_Rec_Type use
      Record
        X1 at 0 range 0 .. -1;                   -- Minus 1  !!
      End Record;

   Y_Rec : Y_Rec_Type := (X1 => X);

   function convert is new unchecked_conversion (X_type, natural);
begin

   put_line("X_Type'size     = " & X_Type'size'img);
   put_line("X_Rec_Type'size = " & X_Rec_Type'size'img);
   put_line("X_Rec'size      = " & X_Rec'size'img);
   put_line("Y_Rec_Type'size = " & Y_Rec_Type'size'img);
   put_line("Y_Rec'size      = " & Y_Rec'size'img);
   put_line("X_Rec.X1        = " & convert(X_Rec.X1)'img);
   put_line("Y_Rec.X1        = " & convert(Y_Rec.X1)'img);

end test1;

Re: Enumeration representation clause surprise.

[Mike Silva]

On Jun 12, 2:41 pm, Markus Schöpflin <nos...@nospam.org> wrote:
> Mike Silva schrieb:
>
> > On Jun 12, 4:45 am, Markus Schoepflin <nos...@no.spam> wrote:
> >> Both GNAT and Dec Ada return 1 and 2 for both A1 and A2, so they are
> >> correctly debiasing when explicitly asked for the internal representation.
>
> >> Markus
>
> > Now I'm really confused.  In your OP you showed some "incorrect"
> > binary values - how did you get those values?  By inspecting memory?
>
> Yes.
>
> > Now you talk about explicitly asking for the internal representation.
> > What does that mean exactly?
>
> Using unchecked conversion to ask for the value of the variables.
>
> > 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.

Mike

Re: Enumeration representation clause surprise.

[Simon Wright]

Mike Silva <snarflemike@yahoo.com> writes:

> 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.

The only reason I have ever written representation clauses is to
ensure that the contents of raw memory are what some external hardware
(or software, eg at the other end of a network connection) requires
them to be. So I really really don't want the compiler to do anything
other than what I asked for; and if it can't, to reject the
representation loudly and fatally!

Given OP's declarations

   type Enum_T is (One, Two);
   for Enum_T use (One => 1, Two => 2);

   type Record_T is record
      A1 : Enum_T;
      A2 : Enum_T;
   end record;
   for Record_T use record
      A1 at 0 range 0 .. 0;
      A2 at 1 range 0 .. 7;
   end record;
   for Record_T'Size use 2 * 8;

   Foo : Record_T;

there's a huge difference between an unchecked conversion of the value
Foo.A1 to <whatever>, which might quite reasonably have the bias
removed, and UC of the value Foo as a whole, which wouldn't.

Re: Enumeration representation clause surprise.

[Samuel Tardieu]

> Interesting. I had been playing with a similar example, and have
> modified it a bit to present. What got me is the record type with
> length 1 but an object with that type that was length zero!

The only possible value for X_Type is X. This requires 0 bit of
information to represent this fact.

> (It compiles without any warnings).

With the proposed patch, it gives:

GNAT 4.4.0 20080611 (experimental)
Copyright 1992-2008, Free Software Foundation, Inc.

Compiling: test1.adb (source file time stamp: 2008-06-12 21:22:24)

    26.         X1 at 0 range 0 .. -1;                   -- Minus 1 !!
                   |
        >>> warning: component representation will be biased

 42 lines: No errors, 1 warning

Re: Enumeration representation clause surprise.

[Adam Beneschan]

On Jun 12, 2:26 pm, Samuel Tardieu <s...@rfc1149.net> wrote:
> > Interesting. I had been playing with a similar example, and have
> > modified it a bit to present. What got me is the record type with
> > length 1 but an object with that type that was length zero!
>
> The only possible value for X_Type is X. This requires 0 bit of
> information to represent this fact.
>
> > (It compiles without any warnings).
>
> With the proposed patch, it gives:
>
> GNAT 4.4.0 20080611 (experimental)
> Copyright 1992-2008, Free Software Foundation, Inc.
>
> Compiling: test1.adb (source file time stamp: 2008-06-12 21:22:24)
>
>     26.         X1 at 0 range 0 .. -1;                   -- Minus 1 !!
>                    |
>         >>> warning: component representation will be biased

So what would the value of the bias be?

                            -- Adam

Re: Enumeration representation clause surprise.

[Mike Silva]

On Jun 12, 4:52 pm, Simon Wright <simon.j.wri...@mac.com> wrote:
> Mike Silva <snarflem...@yahoo.com> writes:
> > 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.
>
> The only reason I have ever written representation clauses is to
> ensure that the contents of raw memory are what some external hardware
> (or software, eg at the other end of a network connection) requires
> them to be.

OK, I understand that - so how would you pass this raw memory to the
external hardware or software?  And in this case, how did the use of
biased representations ever get into compilers at all?  Is there any
possible use of biased representations that does not fail the
requirement you have established?

I'm not arguing, just trying to understand the issue.

Mike

Re: Enumeration representation clause surprise.

[Simon Wright]

Mike Silva <snarflemike@yahoo.com> writes:

> On Jun 12, 4:52�pm, Simon Wright <simon.j.wri...@mac.com> wrote:

>> The only reason I have ever written representation clauses is to
>> ensure that the contents of raw memory are what some external
>> hardware (or software, eg at the other end of a network connection)
>> requires them to be.
>
> OK, I understand that - so how would you pass this raw memory to the
> external hardware or software?

Obtain the address to which the hardware registers are mapped (talking
VME here) & convert to a pointer to a structure which describes how
the hardware expects to see memory, then write through that pointer.

Or, for example, function To_Stream_Element here:

http://coldframe.cvs.sourceforge.net/coldframe/adasntp/SNTP.impl/sntp_support.adb?revision=1.4&view=markup

where I'm packing an unrepresented Status into a single byte for
transmission.

Nowadays I might do this using shift-and-mask to avoid messing with
endianness (this code has to work with Ada 95, even if the new 05
features would help).

>                                 And in this case, how did the use of
> biased representations ever get into compilers at all?  Is there any
> possible use of biased representations that does not fail the
> requirement you have established?

If I don't care how the compiler wedges the data into the record so
long as it's as small as possible (pragma Pack) then a biased rep
would be quite reasonable.

Re: Enumeration representation clause surprise.

[Samuel Tardieu]

> > Compiling: test1.adb (source file time stamp: 2008-06-12 21:22:24)
> >
> >     26.         X1 at 0 range 0 .. -1;                   -- Minus 1 !!
> >                    |
> >         >>> warning: component representation will be biased
> 
> So what would the value of the bias be?

Yes, I've noticed too that the error message could be improved in this
particular case, as here "biased" means "different from what you might
expect".

Re: Enumeration representation clause surprise.

[Keith Thompson]

Mike Silva <snarflemike@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.

-- 
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"

Re: Enumeration representation clause surprise.

[Peter Hermann]

Samuel Tardieu <sam@rfc1149.net> wrote:
>     26.         X1 at 0 range 0 .. -1;                   -- Minus 1 !!

this is a null range: LRM3.5(4)

Re: Enumeration representation clause surprise.

[christoph.grein]

> > With the proposed patch, it gives:
>
> > GNAT 4.4.0 20080611 (experimental)
> >     26.         X1 at 0 range 0 .. -1;                   -- Minus 1 !!
> >                    |
> >         >>> warning: component representation will be biased
>
> So what would the value of the bias be?

  type X_Type is ( X );
  for x_type use (x => 16#7FFF_FFFF#);

16#7FFF_FFFF# of course

Since this is the only value, nothing need be stored to know which
value it is. This is like a constant in ROM, I gather.

Re: Enumeration representation clause surprise.

[Jean-Pierre Rosen]

Mike Silva a �crit :
> 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.
> 
It would be interesting to add a pragma Volatile to the variable. It's a 
way of saying that you are serious about what's written in memory...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Enumeration representation clause surprise.

[Mike Silva]

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.
>- 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"?

Re: Enumeration representation clause surprise.

[Markus Schoepflin]

Mike Silva wrote:

> 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.

In the project where I was bitten by this, it is clearly not the first time
that this problem has occurred.

In my search for other occurrences of the problem in the full source code
(a few million SLOC) of the system, I discovered an old comment dating back
from 1996, indicating that they had the same issue back then.

> Aren't biased representations fundamentally incompatible with "the 
> representation clearly *does* matter"?

 From my point of view, biased representations and representation clauses
should be mutually exclusive. Whenever I care enough about the 
representation that I think it necessary to write a representation clause, 
the compiler shouldn't fiddle with that representation behind my back.

Markus

Re: Enumeration representation clause surprise.

[Samuel Tardieu]

Peter Hermann:

> Samuel Tardieu <sam@rfc1149.net> wrote:
> >     26.         X1 at 0 range 0 .. -1;                   -- Minus 1 !!
> 
> this is a null range: LRM3.5(4)

Exactly. And this null range can represent 2^0 = 1 value. Which is the
case in this example.

Re: Enumeration representation clause surprise.

[Adam Beneschan]

On Jun 13, 1:27 am, christoph.gr...@eurocopter.com wrote:
> > > With the proposed patch, it gives:
>
> > > GNAT 4.4.0 20080611 (experimental)
> > >     26.         X1 at 0 range 0 .. -1;                   -- Minus 1 !!
> > >                    |
> > >         >>> warning: component representation will be biased
>
> > So what would the value of the bias be?
>
>   type X_Type is ( X );
>   for x_type use (x => 16#7FFF_FFFF#);
>
> 16#7FFF_FFFF# of course
>
> Since this is the only value, nothing need be stored to know which
> value it is. This is like a constant in ROM, I gather.

My point is that the "bias" is the difference between the (conceptual)
value being represented, and the number actually stored in memory.  So
what number is stored in a 0-bit data item?  I suppose you could
arbitrarily decide it's zero (which would make some sense
mathematically) but it seems more commonsensical to say that nothing
is stored there because there ain't no bits to store anything in.

                              -- Adam

Re: Enumeration representation clause surprise.

[Keith Thompson]

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"

Re: Enumeration representation clause surprise.

[John B. Matthews]

In article <878wx9bdda.fsf@willow.rfc1149.net>,
 Samuel Tardieu <sam@rfc1149.net> wrote:

> Peter Hermann:
> 
> > Samuel Tardieu <sam@rfc1149.net> wrote:
> > >     26.         X1 at 0 range 0 .. -1;                   -- Minus 1 !!
> > 
> > this is a null range: LRM3.5(4)
> 
> Exactly. And this null range can represent 2^0 = 1 value. Which is the
> case in this example.

But null (o, \u00F8) is not zero. The range 0 .. -1 is "a null range, 
and [it] specifies an empty set of values." [LRM3.5(4)] If I understand 
it correctly, the value 2^0 is the power set of o, {o}, a set with one 
element, which is the empty set.

John
-- 
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews

Re: Enumeration representation clause surprise.

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

>...So
> what number is stored in a 0-bit data item?

Zero.

An n-bit field is either signed or unsigned.
When you load the field into a register, you
take all the bits and add copies of the sign bit on the left
(for signed) or zeros on the left (for unsigned).

A 0-bit field must be unsigned (there's no sign bit!).
So you take nothing, and add 32 zero bits on the left
(on a 32-bit machine).

Or you could think of it as an infinitely-long string of bits -- you
sign extend or zero extend infinitely on the left to get the value.

Then of course you can bias that 0 by anything -- range 100..100
can be stored in a zero-bit unsigned bitfield, biased by 100.
(Or is that -100?)

>...I suppose you could
> arbitrarily decide it's zero (which would make some sense
> mathematically)

Yes, I think so.

>... but it seems more commonsensical to say that nothing
> is stored there because there ain't no bits to store anything in.

But that view requires a special case.

The natural unsigned range for n bits, where n >= 0,
is 0..(2**n)-1.  Which is 0..0 when n = 0.

The natural signed (2's complement) range for n bits, where n > 0,
is -(2**(n-1))..(2**(n-1))-1.  Which makes no sense
if n = 0, because we don't want to mess around with
negative exponents (fractions) -- we're talking about
integer ranges.

- Bob

Re: Enumeration representation clause surprise.

[Adam Beneschan]

On Jun 15, 12:33 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Adam Beneschan <a...@irvine.com> writes:

> >...I suppose you could
> > arbitrarily decide it's zero (which would make some sense
> > mathematically)
>
> Yes, I think so.
>
> >... but it seems more commonsensical to say that nothing
> > is stored there because there ain't no bits to store anything in.
>
> But that view requires a special case.
>
> The natural unsigned range for n bits, where n >= 0,
> is 0..(2**n)-1.  Which is 0..0 when n = 0.

Right, that does make sense.  I'm not convinced it matters, since all
this mathematics isn't necessariliy going to be self-evident to a poor
user.  This particular subthread was about a warning message that, I
think, could leave the user scratching their head about what it means,
and that isn't a good thing regardless of how sound is the mathematics
on which the warning is based.

                                  -- Adam

Re: Enumeration representation clause surprise.

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

>...This particular subthread was about a warning message that, I
> think, could leave the user scratching their head about what it means,
> and that isn't a good thing regardless of how sound is the mathematics
> on which the warning is based.

Agreed.

- Bob

Re: Enumeration representation clause surprise.

[christoph.grein]

GNAT supports all annexes.

So note C.2(2). From this it follows via 13.3(55,55.b) that U'Size
must be 0 for an unsigned integer subtype U with range 0 .. 1 only.

Re: Enumeration representation clause surprise.

[christoph.grein]

On 17 Jun., 08:03, christoph.gr...@eurocopter.com wrote:
> GNAT supports all annexes.
>
> So note C.2(2). From this it follows via 13.3(55,55.b) that U'Size
> must be 0 for an unsigned integer subtype U with range 0 .. 0 only.

Of course I meant upper bound 0. The same should be true for a biased
representation of a range with one value only.