TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Reply To:
Thu, 23 May 2002 13:08:26 +0100
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.