CVS difference for ais/ai-00167.txt

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

--- ais/ai-00167.txt	2001/01/29 23:33:41	1.3
+++ ais/ai-00167.txt	2001/11/15 02:34:08	1.4
@@ -290,3 +290,182 @@
 The priority of this AI was changed based on ARG discussion in November 2000.
 
 ****************************************************************
+
+From: Steve Baird
+Date: Thursday, November 8, 2001  8:18 PM
+
+Two points were made in the discussions of AI-167 at the 10/01 ARG meeting
+in Minneapolis:
+
+    1) A solution to the problem described in the AI is needed.
+
+    2) Changing the definition of Ada.Unchecked_Conversion is not
+       the right solution. The change that was being considered would
+       have imposed a performance penalty on programs which use
+       Unchecked_Conversion "correctly" (i.e. consistently with the
+       existing language rules).
+
+One can come close to solving the problem using the language
+as it stands today, but the solution is both awkward and obscure.
+
+Consider the following attempt:
+
+     generic
+         type Source (<>) is limited private;
+         type Target is (<>);
+     function My_Unchecked_Conversion (S : Source) return Target;
+
+     with Ada.Unchecked_Conversion;
+     function My_Unchecked_Conversion (S : Source) return Target is
+         type Target_Record is
+              record
+                  F : aliased Target;
+              end record;
+              pragma Pack (Target_Record);
+
+         function Convert is new Ada.Unchecked_Conversion (Source,
+Target_Record);
+         Result : Target renames Convert (S).F;
+     begin
+         if Result'Valid then
+             return Result;
+         else
+             raise Program_Error;
+         end if;
+     end;
+
+The one-field record skin is used to get around 13.9.1(12) and the function
+result rename is used in order to meet the restrictions of 13.9.1(8).
+
+Even ignoring the issues of awkwardness and obscurity, this solution is not
+completely satisfactory. It depends on Target and Target_Record having the
+same representation (this is the motivation for the Pack pragma and for
+declaring
+the component to be aliased). Corresponding values of the two types would
+typically have the same representation, but relying on this assumption when
+trying to
+write portable code is undesirable.
+
+To address these problems, I propose adding the following language-defined
+generic functions:
+
+     generic
+         type Source (<>) is limited private;
+         type Target is (<>);
+     function Ada.Validated_Discrete_Conversion (S : Source) return Target;
+     pragma Convention (Intrinsic, Ada.Validated_Discrete_Conversion);
+     pragma Pure (Ada.Validated_Discrete_Conversion);
+
+     generic
+         type Source (<>) is limited private;
+         type Target is digits <>;
+     function Ada.Validated_Float_Conversion (S : Source) return Target;
+     pragma Convention (Intrinsic, Ada.Validated_Float_Conversion);
+     pragma Pure (Ada.Validated_Float_Conversion);
+
+     generic
+         type Source (<>) is limited private;
+         type Target is delta <>;
+     function Ada.Validated_Fixed_Conversion (S : Source) return Target;
+     pragma Convention (Intrinsic, Ada.Validated_Fixed_Conversion);
+     pragma Pure (Ada.Validated_Fixed_Conversion);
+
+     generic
+         type Source (<>) is limited private;
+         type Target is delta <> digits <>;
+     function Ada.Validated_Decimal_Conversion (S : Source) return Target;
+     pragma Convention (Intrinsic, Ada.Validated_Decimal_Conversion);
+     pragma Pure (Ada.Validated_Decimal_Conversion);
+
+These would be defined to return the same value as would be produced
+by a corresponding instance of Ada.Unchecked_Conversion except in the
+case where that result would be invalid; in that case, Program_Error
+is raised (this definition would require formalizing).
+
+Most (all?) existing implementations could provide these units without any
+special compiler support; simply copy the body given in the preceding example,
+changing the unit name appropriately. The key advantage of having this unit be
+language-defined is portability; the burden is on the compiler vendor, not on
+the user, to ensure that that the unit is implemented correctly.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, November 8, 2001  9:28 PM
+
+why are these packages any different from doing an unchecked conversion
+followed by a validity check?
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Friday, November 9, 2001  1:45 AM
+
+Because as the language stands today you may become erroneous as soon as you
+do the unchecked conversion, even before you have a chance to do the
+validity check.  I suggest reading the AI for details of the problem.  And
+this is not just an angel-on-a-pinhead issue, it shows up in real life
+because optimizers do make assumptions that may make the erroneousness very
+visible (e.g., leading to 'Valid being optimized away).
+
+****************************************************************
+
+From: Robert Dewar
+Date: Friday, November 9, 2001  5:53 AM
+
+OK, I understand, but I must say that a compiler that optimizes away 'Valid
+under any circumstances seems broken from a pragmatic point of view to me.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Friday, November 9, 2001  6:01 AM
+
+By the way, in GNAT we handle this by guaranteeing that the sequence of
+an unchecked conversion followed by a validity check is always correct,
+and we never ever optimize valid checks away (it seems really really
+wrong to me to optimize a valid check away, after a validity check
+you should be able to assume the data is valid, and that includes
+checking for validity errors caused by random data clobbering etc,
+the compiler is never ever justified in optimizing away a valid
+check. Yes, I know we have no formal way of saying this, but in
+pragmatic terms this is a very important informal requirement.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, November 14, 2001  7:52 PM
+
+I think the units are fine, and you should go ahead and complete the write-up
+of the AI, including wording. :-)
+
+> Most (all?) existing implementations could provide these units without any
+> special compiler support; simply copy the body given in the preceding example,
+> changing the unit name appropriately.
+
+Well, the body wouldn't work for Janus/Ada, because the size of component of a
+generic formal integer type is the size of the largest possible integer type.
+And pragma Pack is ineffective on such types. (The results of generic code
+sharing.) Thus, you probably would get a type mismatch error on the
+Unchecked_Conversion instantiation.
+
+But I don't think that the burden of building these into the compiler would be
+high enough to be a problem. (I don't think our optimizer reasons from
+erroneousness; we wanted to be able to detect random data values that came from
+any source. If we were redoing it for Ada 95, I think we'd take a tack much
+like Robert outlined - only worry about random values at a 'Valid check.)
+
+Robert said:
+
+>I must say that a compiler that optimizes away 'Valid
+>under any circumstances seems broken from a pragmatic point of view to me.
+
+I think that is a little bit too strong: if the compiler can determine that the
+value being tested is known to be set to one or more valid, static values in
+the current extended basic block (via flow analysis, for example), then it can
+remove the check. Certainly if the value is known to be static. But those cases
+are likely to be rare enough that it may not be worth it to allow them.
+
+****************************************************************
+
+

Questions? Ask the ACAA Technical Agent