!standard  7.5(8.2/3)                             10-06-13    AI05-0218-1/00
!class binding interpretation 10-06-13
!status work item 10-06-13
!status received 10-04-15
!priority Low
!difficulty Hard
!qualifier Omission
!subject Generics and volatility

!summary

** TBD **

!question

The language tries to prevent an access value from denoting a volatile object of
a nonvolatile type.

The following example seems to violate this rule.

   procedure Volatility_Test is
     type T1 is record Field : aliased Integer; end record;
     type T2 is new T1;
     pragma Volatile (T2);

     generic
        type Formal_Derived is new T1;
     package G is
        X : Formal_Derived;
        type Ref is access all Integer;
        Ptr : Ref;
     end G;
     package body G is
     begin
        Ptr := X.Field'Access;
     end G;
     package I is new G (T2);
   begin
     I.Ptr.all := I.Ptr.all + 1; -- problematic references to a volatile
     null;
     -- I.Ptr := I.X.Field'Access; -- clearly illegal
   end Volatility_Test;

Should this be fixed?

!recommendation

(See Summary.)

!wording

** TBD **


!discussion



!ACATS Test

Add a B-Test to check that this type is classified as "immutably limited".

!appendix

From: Steve Baird
Sent: Thursday, April 15, 2010  7:35 PM

> It seems like the case ought to be detected, or at least we ought to
> consider if the problem is severe enough to fix (as the fix will be
> incompatible).

Ok, I'll inflict this one on the group.

The language tries to prevent an access value from denoting a volatile object of
a nonvolatile type.

The following example seems to violate this rule.
Does this warrant fixing?

   procedure Volatility_Test is
     type T1 is record Field : aliased Integer; end record;
     type T2 is new T1;
     pragma Volatile (T2);

     generic
        type Formal_Derived is new T1;
     package G is
        X : Formal_Derived;
        type Ref is access all Integer;
        Ptr : Ref;
     end G;
     package body G is
     begin
        Ptr := X.Field'Access;
     end G;
     package I is new G (T2);
   begin
     I.Ptr.all := I.Ptr.all + 1; -- problematic references to a volatile
     null;
     -- I.Ptr := I.X.Field'Access; -- clearly illegal
   end Volatility_Test;

Note that C.6(12) currently includes the following:
   ...
   If an atomic type is used as an actual for a generic formal derived
   type, then the ancestor of the formal type shall be atomic or allow
   pass by copy. Corresponding rules apply to volatile objects and
   types.

One solution would be to delete the "or allow pass by copy" wording, although
that change would affect the atomic case as well.

****************************************************************

From: Randy Brukardt
Sent: Thursday, April 15, 2010  8:03 PM

It should be noted that this rule potentially inflicts a large burden on
implementations that do generic sharing, as it essentially requires anything
whose actual type can be volatile (or atomic) to be passed by copy if that is
allowed at all. For types that allow passing by copy but that the compiler would
normally pass by reference (such as larger composite types), this can be very
expensive. (Alternatively, the compiler could revert to non-sharing semantics
when any actual might be volatile or atomic, but of course that would limit the
sharing possibilities fairly significantly.)

There also seems to be an issue if the compiler choose in the example above to
pass the type by reference in any primitive subprograms. Humm...(answering own
question)...actually T1 int eh example above can't have primitive subprograms
(else the pragma is illegal). So scratch this issue.

Anyway, the sharing issue alone would not be worth changing the language for,
but it seems to provide an additional data point that the existing rule is
dubious.

****************************************************************

From: Robert Dewar
Sent: Thursday, April 15, 2010  8:08 PM

I am not normally very sympathetic to Randy's concerns about generic sharing,
but in this particular case, I think he has a really good point. This definitely
needs fixing in my view.

****************************************************************