CVS difference for ais/ai-00270.txt

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

--- ais/ai-00270.txt	2002/10/24 17:12:04	1.2
+++ ais/ai-00270.txt	2002/10/29 20:24:57	1.3
@@ -2417,3 +2417,43 @@
+From: Tucker Taft
+Sent: Thursday, October 24, 2002   2:31 PM
+Here is a problem relating to the new AI on Stream_Size, with Randy's response.
+I wrote:
+ > Someone pointed out a problem with this as written.
+ > When writing out a composite object, the calls to
+ > Write components should not perform any kind of constraint
+ > check if the component doesn't have a default expression,
+ > because it can legitimately be uninitialized, and hence
+ > stack junk.
+ >
+ > That seems right, but I am not sure how to deal with it.
+ > I suppose the simplest solution is to drop the Constraint_Error
+ > check.  That seems unfriendly.  I suppose another is to
+ > require that the constraint check is bypassed when called
+ > from the predefined composite Write for an array, or a record
+ > when the component lacks a default expression.  I guess
+ > that could work.  It implies a bit more magic, but these
+ > are attributes, so magic is allowed, I guess.
+ >
+ > Don't ask how this interacts with holey enumeration types ... ;-)
+Randy wrote:
+So, how does this interact with holey enumeration types? :-) :-)
+I'll leave this problem as an exercise for the author. Meaning, I don't
+know. I'm uncomfortable with having a different semantics for attributes
+when they compose than when they don't. But I don't suppose it is that awful
+to implement. Perhaps the Constraint_Error check should be made only for
+explicit calls to 'Write? It would be cleaner to say it is never done for
+components (even though it would be safe if the component isn't
+uninitialized). That would be easier to implement (the check would only be
+part of explicit, rather than implicit calls to the attributes).

Questions? Ask the ACAA Technical Agent