CVS difference for ai12s/ai12-0074-1.txt
--- ai12s/ai12-0074-1.txt 2013/11/05 00:33:13 1.6
+++ ai12s/ai12-0074-1.txt 2014/06/19 05:34:08 1.7
@@ -1,4 +1,4 @@
-!standard 4.6(56) 13-07-08 AI12-0074-1/03
+!standard 4.6(56) 15-05-28 AI12-0074-1/04
!class binding interpretation 13-06-09
@@ -9,12 +9,13 @@
-!subject View conversions and scalar out parameters passed by copy
+!subject View conversions and out parameters passed by copy
Scalar view conversion values are well defined if the Default_Value aspect
-of the target type is specified.
+of the target type is specified. Access type view conversions are not allowed
+for unrelated types.
@@ -91,19 +92,23 @@
Append to end of 6.4.1 Legality Rules section:
- If the mode is *out*, the type of the formal parameter is a
- a scalar type that has the Default_Value aspect specified,
- and the actual parameter is a view conversion, then
+ If the mode is *out*, the actual parameter is a view conversion,
+ and the type of the formal parameter is a
+ a scalar type that has the Default_Value aspect specified, then
- the type of the operand of the conversion shall have the
Default_Value aspect specified; and
- there shall exist a type (other than a root numeric type) that is
an ancestor of both the target type and the operand type.
+ Similarly, if the mode is *out*, the actual parameter is a view
+ conversion, and the type of the formal parameter is a
+ an access type, then there shall exist a type that is an ancestor of
+ both the target type and the operand type.
In addition to the places where Legality Rules normally apply
- (see 12.3), this rule applies also in the private part of an
+ (see 12.3), these rules also apply in the private part of an
instance of a generic unit.
- AARM note: This rule is needed in order to ensure that a well-defined
- parameter value is passed in.
+ AARM note: These rules is needed in order to ensure that a well-defined
+ parameter value is passed.
@@ -214,35 +219,14 @@
and the parent type, and of course the types are related in this case. That means
that all affected view conversions will be explicit in the program.
-We do not use a Legality Rule to handle the more minor issue with access types,
-as that would be incompatible with existing Ada code.
+We use a similar Legality Rule to handle the more minor issue with access types.
+Note that this will be incompatible in rare cases (access type view conversions
+are rare in existing code, and ones that would trigger the rule should be much
+rarer). Also note that unlike scalar types, it is not that uncommon to read
+an "out" access parameter, in order to check bounds or discriminants of the
+designated object. This means that the problematic case is more likely to
+occur in practice.
-[Editor's note: Steve and I strongly disagree on how to handle the access type case.
-Steve argues that the language is well-defined and that any compiler that choses
-an access representation that cannot be converted in both directions without information
-loss is simply wrong. I argue that such cannot be the intent of the language, as it would
-effectively require all access types to be represented the same. In the case of a machine
-where interfacing to a language like C requires expensive byte-pointers rather than cheaper
-word-pointers, it would prevent Ada from using the word pointers at all if it wants to
-support C interfacing. A similar issue would arise if some access types needed to support
-x86 segments (which would be far more expensive than unsegmented access types). If Steve's
-intrepretation holds, then the only way to have a useful compiler in these situations would
-be to ignore the standard. That's not a direction that we want to go. (Late breaking
-update: Steve says he finds my segmented address example convincing. But he's not sure
-what the check should be.)
-I still believe that it should be a Bounded Error to do an untagged elementary view
-conversion for any target type with an implicit initial value if the representations of
-the types differ; the possible results being Constraint_Error, Program_Error, or works
-properly (no information loss). (And I wouldn't bother with the runtime check for the
-generic cases above, as the bounded error would cover them.) This way, a compiler only
-need to make a check if a representation change is involved, and any result will not fit.
-I would not include the value in the bounded error conditions, so a safety-critical compiler
-could always raise Program_Error if any case would fail; alternatively, the check could be
-made on the value (this is what Janus/Ada's code generator actually does, whether the
-language allows it or not, since we're not going to lose information or generate wildly
An alternative solution was to initialize the parameter with the
@@ -267,6 +251,24 @@
the previously initialized value of Obj is properly initialized and it wasn't
changed. This does not seem acceptable, especially as the similar rules
for access types do not have this effect.
+A different alternative solution would be to declare the parameter to be abnormal
+in cases where the legality rule would be triggered. This would make the program
+erroneous if (and only if) the parameter was actually read (which doesn't happen
+for many out parameters. The problem with this is that it introduces a new
+kind of erroneous execution.
+A possibility to minimize both the incompatibility and the possibility of
+erroneousness is to use a suppressible error here (presuming that we define
+those, see AI12-0092-1). In that case, the programmer would have to take
+explicit action (suppress the error) to cause the possibility of erroneous
+execution. That might be the best solution for this case (because the
+incompatibility can be easily avoided by suppressing the error as well as
+by introducing a temporary), but it depends on us having decided to
+define suppressible errors.
Questions? Ask the ACAA Technical Agent