CVS difference for acs/ac-00016.txt

Differences between 1.2 and version 1.3
Log of other versions for file acs/ac-00016.txt

--- acs/ac-00016.txt	2001/10/19 01:36:42	1.2
+++ acs/ac-00016.txt	2001/11/15 02:34:08	1.3
@@ -147,3 +147,166 @@
 end West_Coast_Consts;
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 18, 2001  9:18 PM
+
+[Perhaps this was already suggested?]
+
+One quite efficient way to accomplish this is to make the
+variable aliased but in the private part, and then export an
+access-to-constant pointing to it, as follows:
+
+package P is
+    type T is ...;
+
+    type Acc_Const_T is access constant T;
+    Read_Only_Ptr : constant Acc_Const_T;  -- Read_Only_Ptr.all is read-only
+...
+private
+    Read_Write_Variable : aliased T;
+    Read_Only_PTr : constant Acc_Const_T := Read_Write_Variable'Access;
+...
+end P;
+
+
+I suppose one simple language change would be to allow a deferred
+"constant" to be completed with a variable declaration.
+However, that might mask true errors.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Friday, October 19, 2001  1:21 AM
+
+I believe that you can do that by completing the deferred constant by a
+pragma Import, and exporting the variable with a pragma Export, both pragmas
+having convention Ada.  Of course, this is assuming that your compiler
+supports these pragmas, but then convention Ada is not too hard to support.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, October 19, 2001 10:05 AM
+
+But one would think that most coding standards should prohibit this usage,
+since it takes you totally outside the Ada type system (it is really
+amazing how much damage pragma Import/Export (Ada does to the Ada model,
+for instance it also allows you to go completely outside the elaboration
+model).
+
+****************************************************************
+
+From: Robert Duff
+Sent: Friday, October 19, 2001 12:13 PM
+
+I evilly use it to put debugging printouts in pragma-Pure packages!
+
+****************************************************************
+
+From: V. Santhanam (Boeing)
+Sent: Friday, October 19, 2001 8:44 AM
+
+I am trying to catch up on the various e-mail messages that have gone back
+and forth on this subject. Let me begin by pointing out that inlining was
+not an option on the programs in which I encountered the need, due to
+certification reasons. If it is not immediately obvious why certification
+authorities have heartburn with inlining, let me know and I will explain the
+rationale.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, October 19, 2001 9:43 AM
+
+<<In GNAT there are restrictions on inlining: (quoting from the user guide):
+
+        "The call appears in a body (not in a package spec).".
+
+Also the -gnatn option must be specified and so must a -O1 or -On
+optimising option.>>
+
+Well in this particular case the restriction on calls in the spec could
+not be an issue, since this would be an access before elaboration error.
+As for requiring optimization for inlining, I see no problem with that.
+
+It seems to me that, for GNAT at least, there is zero penalty for using
+a function for this purpose, so the proposed feature adds no expressive
+power, or efficiency gain.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Sunday, October 21, 2001  3:52 AM
+
+> If it is not immediately obvious why certification
+> authorities have heartburn with inlining, let me know and I will explain
+> the rationale.
+
+But then I fail to see why the same certification authorities would not have
+the same heartburn with pragma Read_Only.  If the problem with inlining is
+that you don't trust the optimizers to do the right thing, then surely
+pragma Read_Only would be much worse.  In essence we would have an object
+which is constant when seen from certain places and variable when seen from
+other places.  Now constancy is a fundamental property for optimizers, as
+they use it to avoid reevaluating certain expressions.  If constancy can
+vary from place to place, I am ready to bet that optimizers would
+occasionally get confused, and assume constancy at the wrong place,
+resulting in plague and pestilence.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Thursday, October 25, 2001  2:46 AM
+
+I believe the certification authorities who don't trust optimizers
+to do the right thing with inlining, don't trust optimizers in general.
+So they insist that the optimizer be turned off.  The idea of pragma
+Read_Only is that it should generate reasonable code without needing
+the optimizer.  Unfortunately, this isn't the only case in Ada where
+optimization is relied on to generate reasonable code.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 25, 2001 12:51 PM
+
+> But then I fail to see why the same certification authorities would not
+> have the same heartburn with pragma Read_Only. ...
+
+An even more important question is why those certification authorities would
+have a problem with Tucker's suggested why to get this behavior in Ada 95
+with very little extra code.
+
+To remind, his suggestion was to export an access-to-constant type and a
+constant object which points at the variable that you need to protect from
+outside modification. The original example would look like:
+
+package Stuff is
+    ...
+    type Access_Error_Count is access constant Natural;
+    Error_Count_Access : constant Access_Error_Count;
+    ...
+private
+    ...
+    Error_Count : aliased Natural := 0;
+    Error_Count_Access : constant Access_Error_Count := Error_Count'access;
+    ...
+end Try;
+
+This is perfectly legal Ada 95. The overhead is only a single dereference
+per use (plus a null check if the compiler is stupid). The accesses can't
+fail (Error_Count_Access is not null). No dynamic allocation is involved
+(one could put an empty storage pool on the type to insure this, if the
+certification guys are freaked out by it).
+
+If one of the Ada 0y proposals is adopted, we could even declare that the
+object cannot be null (eliminating the check and the only realistic
+objection that I can think of):
+
+    type Access_Error_Count is access constant Natural not null;
+
+So why do we need a complex (to implement and describe in RM language) new
+feature here???
+
+****************************************************************

Questions? Ask the ACAA Technical Agent