CVS difference for ais/ai-00279.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00279.txt

--- ais/ai-00279.txt	2002/01/24 04:54:13	1.2
+++ ais/ai-00279.txt	2002/02/05 02:06:24	1.3
@@ -191,3 +191,147 @@
 would make just as much sense to put this issue there. Or open a new AI.
 
 ****************************************************************
+
+From: Steve Baird
+Date: Monday, January 28, 2002   2:27 PM
+
+To recap, AI-279 is a response to the following question:
+
+    T'Class'Input reads in a string, maps it to a tag by calling
+    Tags.Internal_Tag, and dispatches accordingly.
+
+    What happens if the the call to Tags.Internal_Tag yields either
+      a) the tag of some type not covered by T'Class
+    or
+      b) the tag of an abstract type
+    or
+      c) the tag of a type whose freezing point has not
+         yet been elaborated (e.g. a type with a
+         not-yet-elaborated component subtype)?
+
+The answers given in the AI summary are
+    a) raise Constraint_Error
+    b) raise Constraint_Error
+    c) bounded error: raise Program_Error or "the call works normally".
+
+For a & b, this is fine. One might argue for raising Program_Error instead
+of Constraint_Error, but that's a nit. It is important to be clear that
+no dispatching call occurs if the exception is raised; the check precedes
+the call.
+
+I believe the third case should result in erroneous execution.
+
+The suggestion that "the call works normally" or works "as defined by the
+RM"
+is not well defined. The language (specifically, the freezing rules)
+statically prohibits the creation of an object of an unfrozen type. The
+dynamic
+semantics of a statically illegal construct are undefined. With the possible
+exception of the rules pertaining to erroneous execution, the RM does not
+have rules of the form "<blap> is prohibited, but this is what it does at
+runtime if you do somehow manage to get it through the compiler".
+
+Allowing non-erroneous execution in this case might allow a subprogram to
+be called before it can be named (i.e. before the elaboration of its
+initial declaration). This would be new to Ada. It could mean,
+for example, that a one-part subprogram might require an elaboration
+check, or that an elaboration checking implementation strategy based on
+initializing some piece of state at the point of the initial declaration
+of a subprogram and then updating it when the body is elaborated would
+no longer work.
+
+Requiring implementations to detect the error and raise some exception
+would also be a well-defined solution, but would require a fair
+amount of overhead (in execution time, code space, and implementation
+complexity) to cope with a case which, as far as I know, noone
+has ever run into in practice.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, January 28, 2002   3:45 PM
+
+I agree with Steve's position on this point, case c) should be erroneous.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, January 28, 2002   5:07 PM
+
+> I agree with Steve's position on this point, case c) should
+> be erroneous
+
+I made this a bounded error when I wrote up the AI, because I didn't like
+the extent of erroneousness that is caused.
+
+If this is erroneous, then *any* call to 'Input before all tagged types are
+elaborated is potentially erroneous. Moreover, there is no way to prevent
+erroneous execution in that case, because the programmer has no control over
+the data actually read. And, there is no way to detect that there was/might
+be a problem, until you've run off the tracks.
+
+To prevent the erroneousness, you would have to have elaborate pragmas for
+every tagged type that the 'Input might read, which completely defeats the
+purpose of classwide 'Input (and would require adding such pragmas during
+maintenance as tagged types are added).
+
+The only safe thing to do would be to avoid using classwide 'Input until the
+main subprogram starts executing (assuming that all tagged types are library
+level, which is almost always the case). But in reusable code, there would
+be no way to enforce this prohibition, and no way to prevent catastrophe if
+it happened.
+
+So while I'm uncomfortable spending much effort on a rare case, making this
+erroneous would make using 'Input unsafe in any high-reliability system.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, January 28, 2002   9:19 PM
+
+<<The only safe thing to do would be to avoid using classwide 'Input until the
+main subprogram starts executing (assuming that all tagged types are library
+level, which is almost always the case). But in reusable code, there would
+be no way to enforce this prohibition, and no way to prevent catastrophe if
+it happened.
+>>
+
+Indeed that's the only safe thing to do.
+
+<<So while I'm uncomfortable spending much effort on a rare case, making this
+erroneous would make using 'Input unsafe in any high-reliability system.
+>>
+
+If you don't want this to be erroneous, you have a lot more work to do in
+describing what the possible behaviors are. You can't appeal to the "proper
+RM behavior" here, as was pointed out earlier in the thread.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, January 28, 2002   9:47 PM
+
+> <<So while I'm uncomfortable spending much effort on a rare case, making this
+> erroneous would make using 'Input unsafe in any high-reliability system.
+> >>
+>
+> If you don't want this to be erroneous, you have a lot more work to do in
+> describing what the possible behaviors are. You can't appeal to the "proper
+> RM behavior" here, as was pointed out earlier in the thread.
+
+Steve was reacting to my informal description of the semantics. I made no
+attempt to determine the RM wording, since I felt that we needed to discuss
+this at an ARG meeting before putting in that effort.
+
+If it turns out to be impossible to word, then I probably would lean toward
+requiring an access before elaboration check. My original reaction to that was
+(as Steve put it) "would require a fair amount of overhead (in execution time,
+code space, and implementation complexity)", but I've since concluded that
+doing so is no worse than the elaboration check that is needed on every
+user-defined 'Input routine anyway. The only requirement would be that default
+'Input routines actually exist somewhere, which I believe is necessary anyway
+for dispatching. The question is whether the (small) overhead is worth it; Ada
+concludes that is the case for regular subprograms, so it seems hard to argue
+that it shouldn't be the case for the default implementation of 'Input.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent