CVS difference for ais/ai-00246.txt

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

--- ais/ai-00246.txt	2000/11/01 01:05:06	1.1
+++ ais/ai-00246.txt	2000/11/04 01:10:29	1.2
@@ -4,7 +4,7 @@
 !status received 00-10-31
 !priority Medium
 !difficulty Medium
-!subject
+!subject View conversions between arrays of a by-reference type
 
 !summary
 
@@ -2415,27 +2415,39 @@
 ****************************************************************
 
 From: Randy Brukardt
-Sent: Tuesday, October 31, 2000 6:52 PM
+Sent: Wednesday, November 1, 2000 12:54 PM
 
 I don't see how that could work for 'Object_Size (which is
-subtype-specifiable, at least in GNAT). Wouldn't something like:
+subtype-specifiable, at least in GNAT). Wouldn't something like the
+following cause problems?
 
-      type Something is limited null record;
-      for Something'Object_Size use 64;
+      type Something is limited record A : Short_Integer; end record;
+      for Something'Object_Size use 32;
       type Something_Else is new Something;
-      for Something_Else'Object_Size use 32;
+      for Something_Else'Object_Size use 16;
 
       A : Something_Else;
 
       procedure P (L : in out Something) is
       begin
-          L := ...; -- Copies 64 bits(?)
+          L := ...; -- Copies 32 bits(?)
       end P;
 
-     P (Something(A)); -- A is 32-bits.
+     P (Something(A)); -- A is 16-bits.
 
-cause problems? If not, why not?
+Assume Short_Integer is a 16-bit integer type.
 
+Inside of P, the compiler "knows" that L has 32-bits (some of these are
+padding bits). Thus, when selecting instructions, it "knows" that it can
+write 32-bits. On the Intel processors, it is cheaper to copy 32-bits than
+16-bits, so the compiler *could* (it wouldn't have to) use a 32-bit
+instruction rather than a 16-bit instruction to do the copy.
+
+But, since the *real* object L only uses 16-bits, we could overwrite
+something else.
+
+So, is this a problem? If not, why not?
+
 (As the one who got the short stick, and who's going to try to write up a
 consistent model for 'Object_Size, preferably one that is compatible with what
 GNAT does, I'd like to know about any gotcha's before I trip over them.)
@@ -2443,6 +2455,29 @@
 ****************************************************************
 
 From: Robert Dewar
+Sent: Wednesday, November 01, 2000 2:07 PM
+
+When Object_Size is used to extend the size allocated for a non-scalar
+object, it simply creates padding at the end. There is no reasonable
+definition of what these bits *should* be, so the most reasonable
+implementation is simply to leave them unset, and not mess with them,
+otherwise you will find you have to generate inefficient code.
+
+Your example shows that (reminding us of other discussions recently), it
+is not just a matter of inefficient code, but in fact if you unwisely
+decide to copy all the bits you will get into trouble. So you had better
+not do this!
+
+The obvious and efficient implementation for your example is to copy only
+16-bits. Yes, it might be more efficient to copy 32 bits, but it would
+be wrong.
+
+Now I see what the issue here is, and why you thought there was a problem,
+there isn't!
+
+****************************************************************
+
+From: Robert Dewar
 Sent: Friday, October 20, 2000 10:36 AM
 
 <<I think we have heard you and Pascal mention subtype-related
@@ -2852,5 +2887,205 @@
 >
 At long last, we have a *technical* reason for not allowing in out parameters
 in functions! (sorry, couldn't resist :-)
+
+****************************************************************
+
+From:	Randy Brukardt
+Sent:	Wednesday, November 01, 2000 7:58 PM
+
+I'm finishing up writing the AI on the recent discussion, and it strikes me that
+the proposed rule potentially is more incompatible with existing code than
+necessary. I'm not sure that this is worth worrying about (the sort of view
+conversion in question is likely to be very rare), but I wanted to point out the
+issue and a possible solution.
+
+The rule that Tucker proposed and everyone agreed to is: (I've recast it to fit
+into the existing list of rules in 4.6(9-12.1):
+
+In a view conversion, if the target type and the operand type do not have a
+common ancestor, then the component subtype shall not have a private or visibly
+by-reference subcomponent.
+
+
+The problem I have with this rule is that it casts a rather wide net: private
+types are common, and the vast majority of them are not by-reference types. For
+instance, the following example is illegal by the proposed rule:
+
+   package P is
+      type Priv is private;
+      type A1 is array (1..2) of P;
+      type A2 is array (1..2) of P;
+      procedure Proc (X : in out A1);
+   private
+      type Priv is null record;
+   end P;
+
+   with P;
+   procedure PP is
+      Y : P.A2 := ...;
+    ...
+       P.Proc (P.A1 (Y)); -- A view conversion, illegal by the proposed rule.
+   end PP;
+
+This sort of thing is not going to be common, but there doesn't seem to be much
+reason to make it illegal: there certainly is no implementation problem as long
+as the full type isn't by-reference.
+
+The primary reason for this wording is to avoid breaking privateness, and to
+avoid problems with freezing. Pascal has noted that the standard already
+contains at least one legality rule that breaks privateness for by-reference
+types (C.6(12)), so it certainly seems harmless to add another.
+
+The freezing case is more interesting. The issue is that the rule (whatever it
+is) must be able to be determined at the point at which a view conversion can
+occur. If that can happen before the type is frozen, then the rule cannot depend
+on whether the type is really by reference (because the full definition may not
+have been seen yet). However, I believe that it is impossible for an untagged
+view conversion to occur before either of the types that uses it is frozen.
+(Array types are always untagged). Untagged view conversions can only occur as
+[IN] OUT actual parameters. [IN] OUT parameters can only occur in procedures.
+Procedure calls can only occur in bodies. Bodies are always freezing. Therefore,
+no unfrozen type can exist at the point of an untagged view conversion. (Of
+course, this would break down if [IN] OUT parameters were added to functions,
+but this seems unlikely.)
+
+A secondary reason for the wording is to cover generic contract problems. The
+wording above simply "assumes the worst" everywhere in a generic. Considering
+how unlikely triggering this rule is, that probably is best.
+
+Therefore, there seems to be no reason to not simply say "by-reference
+component" in the rule above, and to say "generic formal private type" to cover
+the generic case.
+
+Humm. The original rule does not seem to handle a visible type derived from a
+private type. That unfortunately messes up the wording further. (Is there some
+reason that this is not necessary?)
+
+Anyway, I'm proposing the following rule instead of the one original proposed by
+Tucker. Are there any problems/objections to this rule? Is the compatibility
+issue worth worrying about?
+
+In a view conversion, if the target type and the operand type do not have a
+common ancestor, then the component subtype shall not have a subcomponent that
+has a by-reference type, generic formal private type, or a type derived from a
+generic formal private type.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, November 02, 2000 8:00 AM
+
+> The rule that Tucker proposed and everyone agreed to is: (I've recast it to
+> fit into the existing list of rules in 4.6(9-12.1):
+>
+> In a view conversion, if the target type and the operand type do not have a
+> common ancestor, then the component subtype shall not have a private or
+> visibly by-reference subcomponent.
+
+For those who haven't memorized the RM paragraph numbers, note that this
+is in the section on legality rules for *array* type conversions.  So even
+though the above does not mention arrays explicitly, it implicitly is only
+disallowing certain array view conversions.
+
+> This sort of thing is not going to be common, but there doesn't seem to be
+> much reason to make it illegal: there certainly is no implementation problem
+> as long as the full type isn't by-reference.
+
+But suppose that during maintenance it became by-reference.  That would
+create an annoying ripple effect.
+
+>
+> The primary reason for this wording is to avoid breaking privateness, and to
+> avoid problems with freezing. Pascal has noted that the standard already
+> contains at least one legality rule that breaks privateness for by-reference
+> types (C.6(12)), so it certainly seems harmless to add another.
+
+I certainly don't agree that we want to make the slope slipperier!
+I would rather try to fix C.6(12).  For example, perhaps if a private
+type is volatile or atomic, that fact needs to be exposed in the visible part.
+(I'm not sure whether that is addressing Pascal's concern.  I'm just
+guessing.)
+
+> ...>
+> Humm. The original rule does not seem to handle a visible type derived from
+> a private type. That unfortunately messes up the wording further. (Is there
+> some reason that this is not necessary?)
+
+Isn't an untagged type derived from a private type still private?  I mean, if it
+isn't a private type, what kind of type is it?
+
+> Anyway, I'm proposing the following rule instead of the one original
+> proposed by Tucker. Are there any problems/objections to this rule? Is the
+> compatibility issue worth worrying about?
+>
+> In a view conversion, if the target type and the operand type do not have a
+> common ancestor, then the component subtype shall not have a subcomponent
+> that has a by-reference type, generic formal private type, or a type derived
+> from a generic formal private type.
+
+I don't like breaking privateness for a rare feature like array view conversions.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Thursday, November 02, 2000 8:37 AM
+
+So our Guardian of Private Contract Models is away.  He might not find
+just one more hole to be "harmless".  ;-)
+
+I don't like breaking the contract model, either, even if it's already
+broken in some other case.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 02, 2000 1:44 PM
+
+> But suppose that during maintenance it became by-reference. That would
+> create an annoying ripple effect.
+
+True, but it seems rather unlikely to cause a real hardship: certainly the
+problem will be clear enough.
+
+> I certainly don't agree that we want to make the slope slipperier!
+> I would rather try to fix C.6(12).  For example, perhaps if a private
+> type is volatile or atomic, that fact needs to be exposed in the visible part.
+> (I'm not sure whether that is addressing Pascal's concern.  I'm just
+> guessing.)
+
+To echo Bob and Erhard, I don't think we want to go answering questions that
+were not asked! Especially because a change to this rule could cause
+compatibility problems.
+
+> > Humm. The original rule does not seem to handle a visible type derived from
+> > a private type. That unfortunately messes up the wording further. (Is there
+> > some reason that this is not necessary?)
+>
+> Isn't an untagged type derived from a private type still private?  I mean, if it
+> isn't a private type, what kind of type is it?
+
+Dunno, I don't think the standard ever answers that question. 3.2(4) says that a
+private type is a partial view. The only way the standard shows to get one the
+declaration of the private type (7.3(14)). It seems weird if a derived type
+represents a partial view (because it couldn't have a completion -- so it would
+never represent the full type: but you can't declare objects, etc. with a
+partial view). And it seems weird to represent the full type (because you don't
+have visibility).
+
+In any case, the question needs to be answered in terms of this wording, not
+necessarily in general.
+
+> I don't like breaking privateness for a rare feature like
+> array view conversions.
+
+I'll leave the AI the way I have it (the original Tucker proposal), and we can
+discuss this possible change at the meeting. I just wanted to make the proposal
+so the compatibility problem gets considered.
+
+I mean, if we assume that array view conversions are rare enough, we could just
+make them illegal. (No, I'm not seriously proposing that.) But I would expect
+that the opposition to this change would come from the incompatibility. (Or
+worse still, we would forbid the ACATS from testing the rule for that reason,
+giving us an unenforced rule.)
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent