CVS difference for ais/ai-00350.txt

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

--- ais/ai-00350.txt	2003/10/29 22:54:13	1.2
+++ ais/ai-00350.txt	2004/02/06 05:01:48	1.3
@@ -3884,7 +3884,7 @@
 ****************************************************************
 
 From: Randy Brukardt
-Sent: Monday, October 19, 2003 12:11 PM
+Sent: Monday, October 20, 2003 12:11 PM
 
 > Sorry to reraise this issue, which some folks may be tired of talking
 > about.  But a few weeks ago Randy told me he was filing an AI on the
@@ -3982,6 +3982,238 @@
 around 50% of the allocations in the program text are dynamically sized -
 there are a lot of allocations of generic formal parameters and of
 dynamically sized arrays in the programs that we look at.)
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, October 20, 2003  3:02 PM
+
+> No, you should never cross-post between ARG and Ada-Comment.
+
+OK, sorry.
+
+But doesn't it seem like a shame that the ARG will now debate the issue
+in its ivory tower, and the original questioner doesn't even get to
+listen in, or say anything?  The original question, by the way, is
+getting lost in all the rhetoric generated after Tuck weighed in.
+
+>... There are a
+> number of reasons for this:
+> -- You're making a private e-mail list's address public by so doing. That
+> could lead to people trying to post to ARG that aren't members;
+> -- Most of us are on both lists. By cross-posting, we get the messages
+> twice. Those of us who aren't on both lists have decided to stay out of
+> public technical discussions, and thus have decided to avoid the discussion
+> until it comes up on the ARG agenda.
+> -- By bringing another group into the middle of the discussion, we end up
+> having to rehash all of the arguments again (which is especially annoying
+> given the fact that Bob seems to want to win the argument by sheer volume of
+> messages. :-)
+
+Whereas Randy and Tucker are happy with the status quo (no ACATS test
+for it), so they want to win the argument by ignoring my points,
+and declaring the whole issue unimportant.  :-)
+
+OK, I put a smiley, just like Randy above.  Seriously, I tried reduce my
+verbiage since we discussed it earlier.
+
+> As happened the last time, I can't answer this whole message. But a quick
+> scan showed a couple of disagreements:
+>
+> > Tucker also pointed out that this case is *not* declared erroneous, nor
+> > is it declared "wildly erroneous".  ;-)  This is true.  However, any
+> > program that compares pointers to deallocated objects necessarily has a
+> > bug, because it is impossible to get any useful information from such a
+> > comparison.
+>
+> That's not true. It is useful to compare such objects against null, and
+> indeed that ought to work properly. We use that when streaming in the
+> symboltable in the Janus/Ada compiler -- if a pointer is not null, we read
+> another object from the stream. If it is null, there is no object to read
+> in. This seems to be a generally useful technique, and we don't want to lose
+> it.
+
+OK, I have no objection to that.  I don't think it changes anything
+about the zero-size issue, though.
+
+> > Usually, in Ada, we like compilers to catch bugs (either at
+> > compile time or at run time).  However in this and a few other cases, we
+> > do not wish to require that, because it would greatly harm efficiency.
+>
+> > It would seem useful if an implementation chose to detect such bugs.
+> > Most implementations can't reasonably do that, but I see no reason to
+> > *forbid* such detection.  It would be feasible to detect such bugs in an
+> > implementation that has garbage-collection support, for example.
+> > Therefore, I suggest that the best fix would be to say that "=" when one
+> > or both access values designates a nonexistent (deallocated) object is a
+> > bounded error: it might return either True or False, or it might raise
+> > Program_Error.
+> >
+> > In any case, the wording belongs in Chap 13, not Chap 4.
+>
+> Thus, I totally object to this wording. I'm not against making this a
+> bounded error in general, but the compare against null case should not be an
+> error (or undefined, for that matter).
+
+OK with me.  I suggest we make it a bounded error in the non-null case
+(both operands non-null, and at least one operand fails to point at any
+object, because the object has been freed).
+
+> > ----
+> >
+> > The other point Randy asked me to address is
+> > Address_To_Access_Conversions.  If there is a hole in the semantics of
+> > Address_To_Access_Conversions, then it should be patched in Chap 13.
+> > Using some weird issue related to Address_To_Access_Conversions to
+> > drive the high-level semantics of access equality is a case of the tail
+> > wagging the dog.
+>
+> There is no hole in Address_to_Access_Conversions (AAC). The problem is your
+> insistence on an object-based model for equality compares, with no wiggle
+> room.
+>
+> If you have such a comparison, you then have to say what object the result
+> of an AAC is.
+
+No, I don't.  The semantics of AAC in those weird cases is entirely up
+to the implementation.  In practise, if the user wants to take the
+'Address of an unaliased object, or an address that comes from C,
+etc, and convert it to an access value, then the user has to understand
+the implementation's run-time model, and make sure the bits look "as if"
+the thing were a properly allocated aliased object.  If the user doesn't
+ensure that, then "=" might not work; that's true of many other
+operations, like .all.  And chapter 4 doesn't need to say that!
+
+When considering the chap 4 semantics of "=", all I care about is
+properly allocated aliased objects.  Chap 13 can deal with anything else
+(usually by saying "implementation dependent").  Otherwise, the tail
+wags the dog.
+
+I'm not sure why you pick on AAC.  The same issue arises for
+machine-code inserts, pragma Suppress, and all the other chap 13 stuff.
+(OK, pragma Suppress isn't in chap 13, but it should be.)
+
+>... Otherwise, you have no basis to decide what the answer from
+> such a comparison is. And, as I showed earlier, any answer to this question
+> essentially requires that all objects (not just aliased ones) have to have a
+> unique id. The only way to do that is to disallowing zero-sized objects -
+> and that has a runtime cost, especially for array slices.
+
+No, with my suggested "interpretation" of 4.5.2(12), there is nothing
+forbidding zero-sized unaliased objects.  This is because *everything*
+in chap 4 (and most others) must be understood to have an implicit
+"unless you do some weird chap-13-ish thing".
+
+> ...
+> > Randy made a point related to this, which I have so far failed to
+> > address: he said something about direct calls to Allocate (not via
+> > "new").  Well, I think that's a red herring.  The RM doesn't say
+> > anything about what Allocate must do.  If you call it directly, it does
+> > whatever it does.  The RM just says that *if* Allocate obeys a certain
+> > contract, and *if* it is called via "new", then certain things happen.
+> > There is nothing in the RM that forbids doing the zero check as part of
+> > "new" rather than as part of Allocate, and in fact that implementation
+> > choice is preferable, which is why I advocate requiring it.
+>
+> I very much dislike having the specification of a routine fail to indicate
+> its contract.
+
+Me, too.  But there are lots of preconditions that we can't express in
+Ada.  This one we *could* express, but for compatibility reasons.
+Oh, well.  No big deal.
+
+>... Moreover, any good Ada programmer will include a check for any
+> invariants in a subprogram's implementation; the only check that they would
+> ever omit would be ones implied by the subprogram's specification. You in
+> fact said that you did this yourself. So the net effect is to require a
+> double check, both of which are often dynamic and thus will require code.
+> Allocations are common, so requiring the check at the point of the call will
+> add a substantial amount of code to the system.
+
+My user-defined allocators do have lots of pragmas Assert in them,
+including Assert(size /= 0).  So I suppress these in production mode.
+(Don't give me the old chestnut about lifejackets on land.  You can't
+have it both ways -- if it's too expensive, you have to suppress it.
+Only the engineer building that software can decide.)
+
+>... (Our experience is that
+> around 50% of the allocations in the program text are dynamically sized -
+> there are a lot of allocations of generic formal parameters and of
+> dynamically sized arrays in the programs that we look at.)
+
+But you have to admit that this is a special case for your run-time
+model.  If you're not sharing generic bodies, then the size of a generic
+formal type can be known at compile time.  I am neither surprised nor
+concerned that generic sharing has a run-time cost; it presumably
+benefits by a compile-time gain (and memory savings).
+
+For the kinds of programs *I* write, I would guess that at least 90% of
+all allocations are for small records of compile-time-known size.
+The rest are dynamic arrays.  And yes, Allocate *is* an efficiency
+bottleneck, so I don't want distributed overhead.
+
+Here's a question for compiler vendors: Are there any compilers that are
+capable of inlining the Allocate routine that is implicitly called when
+you do a "new"?  It seems silly to complain about the extra zero check
+(I repeat: can often be optimized away), when the call overhead is
+surely more costly.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, October 20, 2003  8:49 PM
+
+> > Thus, I totally object to this wording. I'm not against making this a
+> > bounded error in general, but the compare against null case should not be an
+> > error (or undefined, for that matter).
+
+Why not? I disagree, it is clearly an error to reference a non-existant
+(freed) access value, and it is just fine if an implementation raises
+program_error in response.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 20, 2003  9:04 PM
+
+> > > Thus, I totally object to this wording. I'm not against making this a
+> > > bounded error in general, but the compare against null case
+> should not be an
+> > > error (or undefined, for that matter).
+>
+> Why not? I disagree, it is clearly an error to reference a non-existant
+> (freed) access value, and it is just fine if an implementation raises
+> program_error in response.
+
+Sigh, I explained it in the original message, which Bob even quoted.
+
+<<That's not true. It is useful to compare such objects against null, and
+indeed that ought to work properly. We use that when streaming in the
+symboltable in the Janus/Ada compiler -- if a pointer is not null, we read
+another object from the stream. If it is null, there is no object to read
+in. This seems to be a generally useful technique, and we don't want to lose
+it.>>
+
+The objects in question are not only freed, they're from a previous program
+run. But there still is useful information there. Comparing an access value
+against null should always work, no matter where the value came from.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, October 20, 2003  10:17 PM
+
+> The objects in question are not only freed, they're from a previous program
+> run. But there still is useful information there. Comparing an access value
+> against null should always work, no matter where the value came from.
+
+The fact that something is useful is not of itself a justification for semantically
+peculiar behavior. Who says that a pointer to a freed access object must compare
+non-null. In a garbage collected environment, it would make eminent sense to set
+such pointers to null forcibly. Furthermore for a pool specific access type,
+there is no requirement that null be some special value, just that it be
+distinguishable from any other object and equal to itself (it would for example
+be fine to have null be a pointer to a special dummy object).
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent