Version 1.2 of ai05s/ai05-0054-3.txt

Unformatted version of ai05s/ai05-0054-3.txt version 1.2
Other versions for file ai05s/ai05-0054-3.txt

!standard 3.3(13)          08-11-01 AI05-0054-3/01
!standard 13.9.1(13)
!class binding interpretation 08-11-01
!status No Action (7-0-1) 08-11-02
!status work item 08-11-01
!status received 08-11-01
!priority Low
!difficulty Hard
!qualifier Omission
!subject Variable views of constant objects
!summary
Modifying a constant by means of an access-to-variable value remains erroneous.
!question
The current instance of a limited type can be used to obtain a variable aliased view of a (limited) constant object.
Are runtime checks needed in order to prevent the modification of a constant? [No.]
!recommendation
No change should be made to the language to solve this issue. See the discussion.
!wording
None needed.
!discussion
The present state of the language ensures that an entity declared with the keyword "constant" is indeed constant in the usual sense of the word, i.e., cannot have its value after it has been initialized (and is not yet being finalized), short of applying unsafe or erroneous programming idioms. Thus the specification implied by the keyword "constant" both by present language rules and by common-sense is preserved by language guarantees. This is of considerable value to the users interested in reliability, safety and security. Of course, a language should preserve a specified object property and Ada05 presently does so.
On the other hand, the practice of obtaining a variable aliased view of objects of limited or controlled type during initialization is an existing idiom that should have a well-defined meaning. This practice is important to provide a practical way of changing the value of "in" parameters, when internal state of the object needs to be changed, but the designer of the interface decided that this "was not the user's business to know". This idiom is generally known as the Rosen-Trick. At present, the semantics of the idiom are well-defined for variable objects as actual parameters of such "in" parameters. However, they are erroneous for constant objects, since the Rosen-Trick then breaks the specification "constant" of the actual.
It follows that, for users of limited (and controlled) types, there is a simple write-around to stay out of erroneousness: Do not declare objects of limited (and controlled) types to be "constant". Given that a limited type lacks assignment anyhow, the semantic difference is marginal: As "constant", the object cannot be passed to "in out" parameters to be changed legally; it can only be passed to "in" parameters where it might be changed (erroneously) by the Rosen-Trick. For writers of libraries, there is an equally simple write-around: do not use an "in" parameter, where the value of the parameter will be changed by the implementation, and thus the Rosen-Trick is not needed.
On balance, trading the well understood principle of constantness of objects against a weaker notion that negates the existence of constant objects alltogether and ties constantness to each separate view of a variable, merely to render the Rosen-Trick well-defined for constants as well, is not warranted.
Other alternatives that were considered: a) raise a run-time exception (AI05-0054-1): apart from implementation
overhead, merely eliminates erroneousness, but does not solve the Rosen-Trick issues.
b) restrict the damage to the constantness concept to constants of
limited and controlled types, which become constant views only (AI05-0054-4)
c) restricting it further to private types (could easily be added to
the semantics of 13.9.1(13) in AI05-0054-4 by mandating that the the access-to-variable value originate from an attribute_reference applied to an aliased variable view of a controlled or immutably limited object of a private type )
d) obsolesce the notion of constants of limited and controlled types
altogether on the grounds that the definer cannot know (not written up).
!ACATS test
Testing erroneousness is not possible.
!appendix


Questions? Ask the ACAA Technical Agent