Version 1.2 of acs/ac-00038.txt

Unformatted version of acs/ac-00038.txt version 1.2
Other versions for file acs/ac-00038.txt

!standard 13.13.2          02-05-30 AC95-00038/01
!class amendment 02-05-30
!status received no action 02-06-07
!subject Stream attributes on tasks, protected types?
!summary
!appendix

!topic Stream attributes on tasks, protected types?
!reference RM95-13.13.2
!from Adam Beneschan 05-30-02
!discussion

13.13.2 indicates that the 'Write, 'Read, 'Output, and 'Input
attributes are defined for every subtype of a specific type, with no
restrictions on what kind of type it is.  Are these attributes defined
for task types and protected types?  If so, what are the semantics of
these attributes in those cases?

Some concerns I have if the RM is to be taken literally: (1) If a task
type or protected type T is declared with discriminants that have
default expressions, T'Read could modify the values of the
discriminants; (2) if T is a protected type, T'Read could modify the
values of its components.

To me, it doesn't make sense to apply these attributes to these types,
and I believe that 13.13.2(2) and 13.13.2(18) ought to be fixed to
exclude task and protected types.

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

topic Stream attributes on tasks, protected types?
!reference RM95-13.13.2
!from Adam Beneschan 06-04-02
!discussion

Earlier I wrote:

> 13.13.2 indicates that the 'Write, 'Read, 'Output, and 'Input
> attributes are defined for every subtype of a specific type, with no
> restrictions on what kind of type it is.  Are these attributes defined
> for task types and protected types?  If so, what are the semantics of
> these attributes in those cases?
>
> Some concerns I have if the RM is to be taken literally: (1) If a task
> type or protected type T is declared with discriminants that have
> default expressions, T'Read could modify the values of the
> discriminants; (2) if T is a protected type, T'Read could modify the
> values of its components.
>
> To me, it doesn't make sense to apply these attributes to these types,
> and I believe that 13.13.2(2) and 13.13.2(18) ought to be fixed to
> exclude task and protected types.

Please ignore this.  I just found the clause in 13.13.2(36) that deals
with this.  My apologies.

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

From: Robert Dewar
Sent: Wednesday, June 6, 2002  8:36 PM

<<13.13.2 indicates that the 'Write, 'Read, 'Output, and 'Input
attributes are defined for every subtype of a specific type, with no
restrictions on what kind of type it is.  Are these attributes defined
for task types and protected types?  If so, what are the semantics of
these attributes in those cases?>>

No, this is careless reading :-)

Read para 36

36   The stream-oriented attributes may be specified for any type via an
attribute_definition_clause.  All nonlimited types have default implemen-
tations for these operations.  An attribute_reference for one of these
attributes is illegal if the type is limited, unless the attribute has been
specified by an attribute_definition_clause.  For an attribute_definition_
clause specifying one of these attributes, the subtype of the Item parameter
shall be the base subtype if scalar, and the first subtype otherwise.  The
same rule applies to the result of the Input function.

Obviously task types are limited, and therefore there is no default
stream attribute.

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

Questions? Ask the ACAA Technical Agent