Re: Enumeration representation clause surprise.

[Adam Beneschan <adam@irvine.com>]

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