CVS difference for ai05s/ai05-0009-1.txt
--- ai05s/ai05-0009-1.txt 2009/06/26 01:49:35 1.14
+++ ai05s/ai05-0009-1.txt 2011/01/31 04:50:12 1.15
@@ -1,4 +1,4 @@
-!standard 9.10(1) 09-05-21 AI05-0009-1/10
+!standard 9.10(1) 09-05-21 AI05-0009-1/10
!standard 13.1(15/1)
!standard 13.2(9)
!standard 13.3(13)
@@ -84,7 +84,7 @@
from the grandparent subtype, but only if the parent subtype statically
matches the first subtype of the parent type. An inherited aspect of
representation is overridden by a subsequent representation item that
-specifies {a different value for} the same aspect of the type or subtype.
+specifies {a different value for} the same aspect of the type or subtype.
AARM Ramification: If an inherited non-confirming aspect is confirmed by
a later representation
@@ -107,7 +107,7 @@
If an Address is specified, it is the programmer's responsibility to ensure
that the address is valid {and appropriate for the entity and its use};
-otherwise, program execution is erroneous.
+otherwise, program execution is erroneous.
AARM Discussion: "Appropriate for the entity and its use" covers cases
such as misaligned addresses, read-only code addresses for variable data
@@ -138,7 +138,7 @@
to denote either an object_declaration, a non-inherited component_declaration,
or a full_type_declaration. {The *component*_local_name in an Independent pragma
shall resolve to denote a non-inherited component_declaration.}
-The *array*_local_name in an
+The *array*_local_name in an
Atomic_Components or Volatile_Components pragma shall resolve to denote
the declaration of an array type or an array object of an anonymous type.
{The local_name in an Independent_Components pragma shall resolve to denote
@@ -299,7 +299,7 @@
from the grandparent subtype, but only if the parent subtype statically
matches the first subtype of the parent type. An inherited aspect of
representation is overridden by a subsequent representation item that
-specifies the same aspect of the type or subtype.
+specifies the same aspect of the type or subtype.
@dby
A derived type inherits each type-related aspect of representation of its
parent type that was directly specified before the declaration of the derived
@@ -311,7 +311,7 @@
from the grandparent subtype, but only if the parent subtype statically
matches the first subtype of the parent type. An inherited aspect of
representation is overridden by a subsequent representation item that
-specifies a different value for the same aspect of the type or subtype.
+specifies a different value for the same aspect of the type or subtype.
!corrigendum 13.2(9)
@@ -331,11 +331,11 @@
@drepl
If an Address is specified, it is the programmer's responsibility to ensure
-that the address is valid; otherwise, program execution is erroneous.
+that the address is valid; otherwise, program execution is erroneous.
@dby
If an Address is specified, it is the programmer's responsibility to ensure
that the address is valid and appropriate for the entity and its use;
-otherwise, program execution is erroneous.
+otherwise, program execution is erroneous.
!corrigendum C.6(2)
@@ -364,7 +364,7 @@
@drepl
The @fa<local_name> in an Atomic or Volatile pragma shall resolve
to denote either an @fa<object_declaration>, a non-inherited @fa<component_declaration>,
-or a @fa<full_type_declaration>. The @i<array_>@fa<local_name> in an
+or a @fa<full_type_declaration>. The @i<array_>@fa<local_name> in an
Atomic_Components or Volatile_Components pragma shall resolve to denote
the declaration of an array type or an array object of an anonymous type.
@dby
@@ -372,7 +372,7 @@
to denote either an @fa<object_declaration>, a non-inherited @fa<component_declaration>,
or a @fa<full_type_declaration>. The @i<component_>@fa<local_name> in an Independent pragma
shall resolve to denote a non-inherited @fa<component_declaration>.
-The @i<array_>@fa<local_name> in an
+The @i<array_>@fa<local_name> in an
Atomic_Components or Volatile_Components pragma shall resolve to denote
the declaration of an array type or an array object of an anonymous type.
The @fa<local_name> in an Independent_Components pragma shall resolve to denote
@@ -383,7 +383,7 @@
@dinsa
If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components applies to a stand-alone
-constant object, then a pragma Import shall also apply to it.
+constant object, then a pragma Import shall also apply to it.
@dinss
It is illegal to apply either an Independent or Independent_Components pragma to
a component, object, or type if the implementation cannot provide the independent
@@ -768,7 +768,7 @@
>> mean major new circuitry for us to figure this out, something like
>> laying out the type with and without rep clauses to see if it came
>> out the same - UGH!
->
+>
> It seems to me that you have this bass-ackwards.
Yes, well I see how it may seem that way if you have not really
@@ -789,7 +789,7 @@
is really difficult since you need a way to test this predicate, and
certainly in our compiler there is easy way to do this.
-I suspect that some people may have an over-naive view of code
+I suspect that some people may have an over-naive view of code
generation for modern processors here ...
> A non-confirming rep. clause *might* have semantics. But it's not
@@ -800,7 +800,7 @@
Might we perhaps remind ourselves of what 9.10 actually says:
However, if packing, record layout, or Component_Size is specified for
- a given composite object, then it is implementation defined whether
+ a given composite object, then it is implementation defined whether
or
not two nonoverlapping parts of that composite object are
independently addressable.
@@ -853,7 +853,7 @@
50 If the Size of a subtype is specified, and allows for efficient
independent addressability (see 9.10) on the target architecture,
- then the Size of the following objects of the subtype should equal
+ then the Size of the following objects of the subtype should equal
the Size of the subtype:
@@ -870,7 +870,7 @@
reading what is there.
> If you need to know if a rep. clause is confirming, there is something wrong
-> with your default representations.
+> with your default representations.
No, that's just wrong, if a rep clause is given you do NOT have
to generate less efficient code to ensure independence! In fact
@@ -1152,12 +1152,12 @@
>> the characters in 8-bit bytes, the above combination would
>> not be valid, since for this type data independence is
>> required.
->
+>
> If you don't have byte operations, the default component size for this array
> cannot be 8. It has to be 16 or 32 or whatever. Or you have to provide
> independence all of the time (and I agree that's too expensive).
-Please read more carefully, we are of COURSE talking about a machine
+Please read more carefully, we are of COURSE talking about a machine
with byte operations here. hat's the WHOLE POINT of this example. Indeed
just think of it as an example for the x86.
@@ -1196,7 +1196,7 @@
why we put a pragma Pack on String, knowing that it destroyed independence.
As for the "old" alphas, there are plenty around, and any serious
-compiler that is intended for general use on the alpha must accomodate
+compiler that is intended for general use on the alpha must accomodate
this architecture.
>> But if I add the "confirming" rep clause
@@ -1205,16 +1205,16 @@
>>
>> Now I can generate the load/and/store sequence since
>> data independence is no longer required.
->
+>
> And then there is no problem, because this isn't confirming on this machine.
-We are talking about a byte addressed machine. I think you fired off
+We are talking about a byte addressed machine. I think you fired off
your response too quickly here, please reread this example carefully.
It applies for instance to the x86.
>> Again, I didn't write this, I am just a reader, and
>> that's what the Ada 95 RM says.
->
+>
> And it's clearly wrong. A rep. clause like the above should never, ever
> change the semantics.
@@ -1299,9 +1299,9 @@
From: Pascal Leroy
Sent: Tuesday, February 21, 2006 2:29 AM
-> > Right, but remember that this rule is wrong; at a least it should say
+> > Right, but remember that this rule is wrong; at a least it should say
> > "non-confirming" like all other rules for rep. clauses.
->
+>
> Yes, but that is incompatible...
I must be a bonehead, but I don't see the incompatibility here.
@@ -1367,7 +1367,7 @@
> Sorry, but any more thought on those AIs wasn't going to lead anywhere. I
> think most of us feel our heads were about to explode when AI-51 was finally
-> finished!
+> finished!
If you feel your head is about to explode, you probably have got
things wrong, and you need more work. You should feel comfortable
@@ -1420,7 +1420,7 @@
> size of char, but I am pretty sure that most of the C code out there
> assumes that it's 8 bits.)
-I agree, that's a bug, probably the understanding is that pragma
+I agree, that's a bug, probably the understanding is that pragma
convention is equivalent to a component size or record rep clause.
But it should be stated.
@@ -1510,12 +1510,12 @@
Sent: Tuesday, February 21, 2006 2:37 PM
> Now, if you had stuck with your original example:
->
+>
> type X is array (0 .. 31) of Character;
> pragma Pack (X);
->
+>
> and
->
+>
> type X is array (0 .. 31) of Character;
> for X'Component_Size use 8;
@@ -1533,7 +1533,7 @@
I think that is fine as implementation advice. I think it is a
horrible error as a requirement, but still I think most compilers
will just ignore it, and no one will notice the difference.
->
+>
> Now, it seems to me that the discussion has pointed out one important point:
> determining if a record rep. clause is confirming is very difficult, so if
> there is a real need to do that, we need to look at exempting it from any
@@ -1553,15 +1553,15 @@
> > type X is array (0 .. 31) of Character;
> > pragma Pack (X);
-> >
+> >
> > and
-> >
+> >
> > type X is array (0 .. 31) of Character;
> > for X'Component_Size use 8;
->
-> To me it is plain horrible to introduce a fundamental
-> difference between the pragma Pack and the component size
-> clause here (given that the Pack must result in a component
+>
+> To me it is plain horrible to introduce a fundamental
+> difference between the pragma Pack and the component size
+> clause here (given that the Pack must result in a component
> size of 8).
This might represent Dewar's interpretation, but it is not borne out by
@@ -1575,16 +1575,16 @@
(eg, String) there might be a significant different between Pack and
Component_Size.
-> > Now, it seems to me that the discussion has pointed out one important
-> > point: determining if a record rep. clause is confirming is very
-> > difficult, so if there is a real need to do that, we need to look at
-> > exempting it from any such requirement. But making that determination
-> > for most rep. clauses is reasonably easy, so there needs to be no
+> > Now, it seems to me that the discussion has pointed out one important
+> > point: determining if a record rep. clause is confirming is very
+> > difficult, so if there is a real need to do that, we need to look at
+> > exempting it from any such requirement. But making that determination
+> > for most rep. clauses is reasonably easy, so there needs to be no
> > exception for them.
->
-> It is not so easy to tell if a component clause if confirming
-> or not, since laying out arrays is highly target dependent,
-> so the determination happens deep in the target dependent
+>
+> It is not so easy to tell if a component clause if confirming
+> or not, since laying out arrays is highly target dependent,
+> so the determination happens deep in the target dependent
> area.
It is not so easy for alignment either: in our implementation the choice
@@ -1593,8 +1593,8 @@
representation clauses have to be neutral (I do) then we have to bite the
bullet, we cannot exempt some of them.
-> Again, we would have to introduce the idea of laying
-> out the type twice, just to see if the component clause was
+> Again, we would have to introduce the idea of laying
+> out the type twice, just to see if the component clause was
> confirming.
As I said earlier we would have to do the same, but somehow it doesn't
@@ -1652,16 +1652,16 @@
Well as long as there is no significant semantic effect, I don't see
the difficulty
->> Again, we would have to introduce the idea of laying
->> out the type twice, just to see if the component clause was
+>> Again, we would have to introduce the idea of laying
+>> out the type twice, just to see if the component clause was
>> confirming.
->
+>
> As I said earlier we would have to do the same, but somehow it doesn't
> seem too bad . In our implementation it wouldn't take more than a couple
> of days. Time well spent if you ask me compared to, say, Unicode support.
> (As usual with implementations, YMMV.)
-This would be a real mess in GNAT, we just wouldn't do it. It would
+This would be a real mess in GNAT, we just wouldn't do it. It would
represent weeks of work, may be more, to completely change the
way types are layed out. That's because the layout occurs very late
in the back end, and we would have to alter the entire interface
@@ -1772,7 +1772,7 @@
>> of there way to provide independence for a given
>> representation *only* when there are no rep. clauses?
>> Seems like most of us have plenty of better things to do.
->
+>
> That's exactly the wrong way round. You have to go
> out of your way to guarantee independence.
@@ -1878,7 +1878,7 @@
But lots of sequences require load-more-than-you-need
mask, store-more-than-you-need. This is after all the
routine code for dealing with packed bit arrays.
->
+>
> In any case, the real question is whether GNAT is doing
> something special to guarantee independence
> for the default representation?
@@ -1928,7 +1928,7 @@
Representation items specify the representation, period. If an algorithm
depends on independence (or doesn't depend on independence -- what the
default should be is a different discussion) it should state it
-explicitly, irrespective of representation items.
+explicitly, irrespective of representation items.
This would make the code much more readable, because you would not have to
interpret the *absence* of a representation item as implying independence.
@@ -1945,9 +1945,9 @@
> Representation items specify the representation, period. If an algorithm
> depends on independence (or doesn't depend on independence -- what the
> default should be is a different discussion) it should state it
-> explicitly, irrespective of representation items.
+> explicitly, irrespective of representation items.
-I strongly agree with this, although it is formally an incompatible
+I strongly agree with this, although it is formally an incompatible
change. So here is a form in which it is compatible:
pragma Independent_Components (type_local_NAME);
@@ -1963,7 +1963,7 @@
use of pragma Independent_Components has no effect (but may
still be useful as clear documentation that separate tasks
may access separate components in an asynchronous manner.
->
+>
> This would make the code much more readable, because you would not have to
> interpret the *absence* of a representation item as implying independence.
> And it would also improve safety and portability, because a combination of
@@ -2025,7 +2025,7 @@
Are there any appropriate restrictions applicable for "pragma
Independent_Components". Specifically, should D.7, Tasking
Restrictions; D.13.1, The "Ravenscar" profile, and H.4 High Integrity
-Restrictions contain a restriction to prevent the use of
+Restrictions contain a restriction to prevent the use of
"Independent_Components"?
@@ -2271,13 +2271,13 @@
At most this could be implementation advice
I do not see why convention should possibly affect independence
->
+>
> AARM 13.1 (8.v, 8.w; 8.gg, 8.hh)
->
+>
> Add independent and independent components, respectively.
->
+>
> C.6
->
+>
> Add pragmas Independent and Independent_Components. Independent
> applies to components of record types; Independent_Components
> applies to components of arrays or anonymous array objects.
@@ -2372,25 +2372,25 @@
> Recommended level of support is always implementation advice.
Not if Annex C is in effect
->
+>
> In any case, we had this discussion right here on the ARG list back in
> February of 2006. Then, you said:
->
+>
>> Indeed. I actually think that there should be a rule that the
>> compiled accept all confirming representation clauses, which
>> is not necessarily the case.
This is reasonable if there are no special semantics associated
with this.
-
+
> To which it was pointed out that there indeed is such a rule in Ada 2005.
->
+>
> Note that further discussion (and an AARM note) points out that it might not
> be possible to write a confirming rep. clause; the rule is intended to be
> read such that if you *can* write such a clause, then it must be accepted.
And that's fine
-
+
> It's also intended that a confirming representation item never have a
> semantic effect. We changed all of the chapter 13 rules to make that true;
> we missed this one on chapter 9. Since the "representation choosen by
@@ -2399,8 +2399,8 @@
> confirm a component size (for one example), you don't lose independence as a
> side-effect.
-I find it awkward and confusing to have this rule. I think it better to
-rely on the new pragmas. After all we are changing the language right
+I find it awkward and confusing to have this rule. I think it better to
+rely on the new pragmas. After all we are changing the language right
now. In Ada 2005, writing a confirming rep clause clearly does kill
independence (even if this was not intended), so it has to be fixed,
and the clean way of fixing it is with the pragmas in any case. It is
@@ -2429,10 +2429,10 @@
> assumes that it's 8 bits.)".
OK, that makes sense
->
+>
> Bibb is just trying to write the AI as the ARG agreed at the last meeting.
-Well it's no big deal in fact, none of this independence stuff is
+Well it's no big deal in fact, none of this independence stuff is
anything any implementor gives a thought to (it just falls out :-))
****************************************************************
@@ -2501,7 +2501,7 @@
> Wouldn't that be fun?
-:-) :-)
+:-) :-)
****************************************************************
@@ -2529,7 +2529,7 @@
Ed:
Note that 9.10 already has references to Annex C, in particular 9.10 (15), so
-maybe the pragmas should be mentioned first at the end of 9.10?
+maybe the pragmas should be mentioned first at the end of 9.10?
Pascal:
I actually think that it would be fine to have a forward reference similar to
@@ -2544,7 +2544,7 @@
where no significant one exists today. Moreover, we originally had a proposal
for a term like "independent addressable object", and it was removed during a
meeting to simplify the presentation. To put it back is completely wrong.
-
+
I think that all that is really needed is a user note to point to 9.10 for the
semantics for pragma Independent.
@@ -2563,33 +2563,336 @@
We now have a major problem, as I am the author of record on this AI, and I
totally disagree with both of you on this one. This could very well kill the AI
in my opinion, or worse make it completely impenetrable and full of bugs.
-
+
(1) Pascal's original suggest of defining a term like "independent object" was
tried in an earlier version of the AI, and it doesn't work. The problem is that
independence is always between *two* objects; there is no such thing as a single
object being independent. The only way that we could find that made sense was to
eliminate the term.
-
+
(2) The definition of independence in 9.10 is very intertwined with the meaning
of the pragmas. I tried factoring them out or inverting the definition, and it
simply does not work. Tucker suggested the current formulation, but it still took
5 or 6 tries to get it right.
-
+
(3) Moving the definition of independence to Annex C makes no sense; this is a
core definition that has no bearing on the pragmas.
-
+
(4) I think the pragmas should be defined in 9.10 (they ought to be a core feature
supported by all implementations), but I lost that battle previously. Someone thought
that they were similar to the existing pragmas in C.6, but it turns out that they
are not at all similar. However, I don't want to be reopening previous decisions
in the absence of a clear error -- which we do not have here.
-
+
As such, the only thing I could see doing here would be to add a redundant
paragraph in C.6 under Static Semantics
-
+
[Pragmas Independent and Independent_Components guarantee independent addressability
for the named object or component, or in the case of a type, for objects of that
type (see 9.10).]
-
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, July 13, 2010 7:51 AM
+
+This AI introduces a lot of implementation-dependent behavior and
+non-portability, is this really intended?
+
+Previously for instance, having two tasks manipulate separate parts of strings
+is wrong, because there is a pragma Pack. Now it's implementation-dependent
+whether such a program is correct.
+
+In general if you add a confirming rep clause, and then assume independence, you
+are in trouble if the compiler later changes its default layout so that the rep
+clause is no longer confirming.
+
+I think it's a real mistake to relax the rule that a rep clause destroys
+independent addrressability, regardless of whether it is conforming or not.
+
+Make the use of the pragma mandatory if there is a rep clause, then at least the
+non-portability shows up as a compile error.
+
+If you decide you want strings to be independently addressable (seems reasonable
+on modern machines), then put the pragma in standard.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, July 13, 2010 10:48 AM
+
+...
+> Previously for instance, having two tasks manipulate separate parts of
+> strings is wrong, because there is a pragma Pack.
+> Now it's implementation-dependent whether such a program is correct.
+
+I don't understand the issue. Previously, it was wrong, but your code might
+work anyway. Now it's wrong if you wanted to write portable code, but your code
+might work anyway. What's the practical difference? As far as I can see, no
+compiler will change its behavoir for String.
+
+By the way, I'm not sure I understand how a pragma Pack can be "confirming".
+
+> In general if you add a confirming rep clause, and then assume
+> independence, you are in trouble if the compiler later changes its
+> default layout so that the rep clause is no longer confirming.
+>
+> I think it's a real mistake to relax the rule that a rep clause
+> destroys independent addrressability, regardless of whether it is
+> conforming or not.
+>
+> Make the use of the pragma mandatory if there is a rep clause, then at
+> least the non-portability shows up as a compile error.
+
+I don't understand that. Surely you're not suggesting that every type with a
+rep clause must also have a pragma Independent. That would be a huge
+incompatibility.
+
+> If you decide you want strings to be independently addressable (seems
+> reasonable on modern machines), then put the pragma in standard.
+
+I do not want strings to be independently addressable.
+I do want strings to be packed on word-addressable machines. (Don't those still
+exist in the embedded and/or DSP worlds?)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, July 13, 2010 10:56 AM
+
+...
+> I don't understand the issue. Previously, it was wrong, but your code
+> might work anyway. Now it's wrong if you wanted to write portable
+> code, but your code might work anyway.
+> What's the practical difference? As far as I can see, no compiler
+> will change its behavoir for String.
+
+But its not wrong if the pragma Pack for string is a confirming rep clause
+(something that is testable by a programmer by defining their own string and
+seeing what behavior it is).
+
+> By the way, I'm not sure I understand how a pragma Pack can be
+> "confirming".
+
+Because the default representation is packed, but if you want to declare that it
+is never confirming, OK with me.
+
+...
+>> Make the use of the pragma mandatory if there is a rep clause, then
+>> at least the non-portability shows up as a compile error.
+>
+> I don't understand that. Surely you're not suggesting that every type
+> with a rep clause must also have a pragma Independent. That would be
+> a huge incompatibility.
+
+Sure, right now, if you have a rep clause you do not have independent
+addressability guaranteed. You only add these pragmas IF you want to assume
+independence.
+
+>> If you decide you want strings to be independently addressable (seems
+>> reasonable on modern machines), then put the pragma in standard.
+>
+> I do not want strings to be independently addressable.
+> I do want strings to be packed on word-addressable machines. (Don't
+> those still exist in the embedded and/or DSP worlds?)
+
+Then if you don't want strings to be independently addressable, make sure that
+you never consider them to be (either by declaring that a pragma Pack is never
+confirming, or by abandoning this (to me misguided) notion that confirming rep
+clauses do not undermine independence.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, July 13, 2010 12:38 PM
+
+> I do not want strings to be independently addressable.
+> I do want strings to be packed on word-addressable machines. (Don't
+> those still exist in the embedded and/or DSP worlds?)
+
+Yes, the Rockwell AAMP is one such processor.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, July 13, 2010 1:00 PM
+
+> By the way, I'm not sure I understand how a pragma Pack can be
+> "confirming".
+>
+
+13.1 (18.2/2)
+A representation item that specifies an aspect of representation that would have
+been chosen in the absence of the representation item is said to be confirming.
+
+13.2(5)
+A pragma Pack specifies the packing aspect of representation
+
+====
+
+I see (at least) two problems with the definition of "confirming":
+
+ 1) If an implementation chooses to look at all sorts of state (e.g.,
+ the current time of day, a checksum of the text of the unit being
+ compiled, etc.) when making compile-time representation choices,
+ this kind of "fork off an alternative universe and see what
+ happens" definition seems to have problems. This is not an issue
+ in practice because compilers don't do this; "comment out the
+ representation item and see if you get the same representation
+ when you recompile" is a test that works in practice.
+
+ 2) Consider the following example:
+
+ type Vec is array (Character) of Boolean;
+ pragma Pack (Vec);
+ for Vec'Component_Size use 1;
+
+ Assume further that we are talking about an implementation where
+ deleting both of the representation items would result in
+ a value greater than one for Vec'Component_Size.
+
+ Are the representation items confirming? Deleting either one
+ of them separately, the representation of the array type might
+ be unaffected (at least for some implementations). One might
+ argue that this means that type Vec is not subject to any
+ non-confirming representation items, but this seems wrong.
+
+ One solution would be to define a set of representation items
+ (rather than a single representation item) to be confirming or not.
+
+I also think the wording "specifies an aspect", as opposed to something like
+"specifies the value of an aspect" is a bit odd, especially for a numeric-valued
+aspect, but that's a minor point.
+
+But let's ignore all that and get back to the question you raised.
+
+Very roughly speaking, I think it was intended that a Pack pragma should be
+confirming if it has no effect on the runtime representation of the type in
+question.
+
+For some implementations, a Pack pragma applied to an array of Standard.Integers
+might be thought of as confirming.
+
+The apparent conflict between this idea and the RM's wording can be resolved if you are willing to accept the idea that an implementation might choose to "specify the packing aspect of representation" in some cases (such an array of integers which is not
subject to any representation items) where a Pack pragma would have no effect on the chosen layout.
+
+What do you think of this idea?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, July 13, 2010 1:13 PM
+
+One problem for us in implementing anything in this area is that we have
+absolutely NO way of telling whether a rep clause is or is not confirming, short
+of laying out everything twice, which is impractical.
+
+So I think we will decide that all rep clauses are non-confirming.
+I fail to see how such a decision can be non-conforming. Steve talks of time of
+day, but in the real world, future versions of the compiler may change things,
+and we don't want to have to constantly worry about such changes, so I think we
+will take a confirming rep clause to mean a rep clause that can be assured to be
+conforming for all time, and decide that there aren't any of these.
+
+Now we take the pragmas for independence and they simply become illegal if there
+are any rep clauses.
+
+This seems a conforming implementation to me, I can't see a legitimate ACATS
+test which would declare otherwise.
+
+Yes, we could have more useful implementations, but I don't see this as
+worthwhile.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, July 13, 2010 1:14 PM
+
+> 1) If an implementation chooses to look at all sorts of state (e.g.,
+> the current time of day, a checksum of the text of the unit being
+> compiled, etc.) when making compile-time representation choices,
+> this kind of "fork off an alternative universe and see what
+> happens" definition seems to have problems. This is not an issue
+> in practice because compilers don't do this; "comment out the
+> representation item and see if you get the same representation
+> when you recompile" is a test that works in practice.
+
+Nope it's not a test that works, since you can't tell if the representation is
+the same (perhaps integers are represented the same, except if they have exactly
+17 1-bits, in which case they are in reverse order -- ludicrous, but you get the
+idea!)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, July 13, 2010 1:34 PM
+
+Good point. The main point I was trying to make is that there is at least a
+theoretical problem here regardless of whether the problem comes up in practice.
+If my assertion that "this is not a problem in practice" was an overstatement,
+that only strengthens the argument that there is a problem here. Ditto for the
+important point you brought up about changes associated with future releases of
+a compiler.
+
+I agree that the implementation you outlined is conforming.
+
+I think we are all in agreement here.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, July 13, 2010 4:48 PM
+
+Since the requirement has little force, I think it would be strengthened by
+making it implementation advice, because in IA we can talk about things more
+freely, and we have a better idea pragmatically what a conforming rep clause is.
+
+I would suggest the following IA
+
+Where possible and practical, the implementation should allow independent access
+to separate components of a single object. In particular, conforming rep clauses
+should not intefere with this capability.
+
+or some such.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, July 13, 2010 11:16 AM
+
+> Sure, right now, if you have a rep clause you do not have independent
+> addressability guaranteed. You only add these pragmas IF you want to
+> assume independence.
+
+But I don't see how you get any compile errors.
+The problematic situations are erroneous.
+
+Still puzzled...
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, July 19, 2010 4:52 PM
+
+ type R is array (1 .. 10) of Boolean;
+ pragma Independent_Components (R);
+ -- fine no problem
+
+ type R2 is array (1 .. 10) of Boolean;
+ for R2'Component_Size use 8;
+ pragma Independent_Components (R2);
+ -- assume this is confirming
+ -- same (unlike Ada 2005)
+
+ type R3 is array (1 .. 10) of Boolean;
+ for R3'Component_Size uae 32;
+ pragma Independent_Components (R3);
+ -- assume this is not confirming
+ -- not required to accept this, but GNAT will accept it
+
+ typr R4 is array (1 .. 10) of Boolean;
+ for R4'Component_Size use 2;
+ pragma Independent_Components (R4);
+ -- Compiler will reject this case
+
****************************************************************
Questions? Ask the ACAA Technical Agent