CVS difference for ai12s/ai12-0074-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0074-1.txt

--- ai12s/ai12-0074-1.txt	2013/07/09 23:36:59	1.4
+++ ai12s/ai12-0074-1.txt	2013/07/18 05:05:31	1.5
@@ -75,12 +75,14 @@
 Reading the value of the view yields the result of converting the value of the
 operand object to the target subtype (which might raise Constraint_Error), except
 if the object is of an {elementary}[access] type and the view conversion is passed
-as an out parameter; in this latter case, the value of the operand object is used
-to initialize the formal parameter without checking against any constraint of the
+as an out parameter; in this latter case, the value of the operand object {may be}[is]
+used to initialize the formal parameter without checking against any constraint of the
 target subtype ({as described more precisely in}[see] 6.4.1). 
 
-[Editor's note: It's not clear to me that this is sufficiently vague to avoid conflict
-with 6.4.1.]
+[We have to use "may be used to initialize" here in order that this is not a lie in
+the case of scalar subtypes without Default_Values, which are uninitialized. This has
+the pleasant side-effect of making this vague enough to make it clear that one has to
+read 6.4.1 for the actual rules.]
 
 Modify AARM 4.6(56.a):
 
@@ -218,14 +220,16 @@
 [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
-lose is simply wrong. I argue that such cannot be the intent of the language, as it would
+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.
+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
@@ -237,7 +241,7 @@
 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
-expensive code just to make Steve happy).]
+expensive code).]
 
 ---
 

Questions? Ask the ACAA Technical Agent