TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Gloster <[log in to unmask]>
Date: Thu, 23 May 2002 13:08:26 +0100
Content-Type: TEXT/plain; charset=us-ascii
MIME-Version: 1.0
Parts/Attachments: TEXT/plain (37 lines)
Somewhere in 4.5.2 of the LRM (I don't have my hardcopy with me and do not feel
like counting the paragraphs):
"Two access-to-subprogram values are equal if they are the result of the same
evaluation of an Access attribute_reference, or if both are equal to the
null value of the access type. [..] It is unspecified whether two access
values that designate the same subprogram but are the result of distinct
evaluations of Access attribute_references are equal or unequal."

At Fri, 17 May 2002 16:23:29 -0700 C. Daniel Cooper said:

"But that's where the risky Ada construct comes in: Ada95 does not
guarantee comparisons of subprogram 'Access values. As explained
in [RM 3.10.2(39)], [RM 4.5.2(13)], and other places, a compiler
"implementation may consider two access-to-subprogram values to be
unequal, even though they designate the same subprogram. This might
be because one points directly to the subprogram, while the other
points to a special prologue that performs an Elaboration_Check and
then jumps to the subprogram." Thus, each 'Access attribute reference
for a given subprogram is allowed to designate a distinct wrapper if
needed, to support an indirect call."

At 21 May 2002 16:24:43 -0500, Wesley Groleau queried:

"To step back from the problem a little bit:

What is the justification, if any, for making a comparison operation
available, and then defining it as meaningless?"

This does not solve anything, but would it be possible to determine whether
the query results come from distinct evaluations of Access
so that the user could treat the comparison answers sceptically if the answers
are not specificed by the Standard. This does not help C. Daniel Cooper in
finding an intuitive approach for his colleagues.