Version 1.1 of acs/ac-00108.txt

Unformatted version of acs/ac-00108.txt version 1.1
Other versions for file acs/ac-00108.txt

!standard 13.9(6)          05-01-27 AC95-00108/01
!class confirmation 05-01-27
!status received no action 05-01-27
!status received 04-11-12
!subject Unchecked_Conversion
!summary
!appendix

!topic Unchecked_Conversion
!reference RM95-13.9(6,7)
!from Grein 2004-11-12
!discussion

I had a discussion with ACT about the differences between Ada83 and Ada95
wrt Unchecked_Conversion, and I forward the relevant parts of the
discussion.

Robert made a remark about some "improper" statements in the RM. I want to
bring this to you attention.
===============================================================================
From: christoph.grein@eurocopter.com
To: report@gnat.com
Date: Mon, 08 Nov 2004 13:34:11 +0100 (CET)
Subject: Unchecked Conversion and Alignments (ACT#691)

You (Robert Dewar) wrote:

"Generally it is much better to use unchecked conversion, which has no
requirements on alignment of the input data (the compiler must do the right
thing, e.g. make a copy, regardless of alignments)."

"... the unchecked conversion between objects with different
alignment should work (it will be inefficient, but that's an inevitable
consequence of the clash in alignments)."

Now I've re-read RM 13.9(7) and found a condition about alignment. So: Does
all of the above really apply generally to any compliant Ada implementation
or is it Gnat specific that UC should work with differing alignments?

RM 13.9(7) would mean that e.g. UC for slices might lead to problems.
===============================================================================
From: dewar@gnat.com
To: christoph.grein@eurocopter.com
Cc: report@gnat.com
Date: Mon, 08 Nov 2004 07:55:18 -0500
Subject: Re: [DB08-001] - Unchecked Conversion and Alignments (ACT#691)

 > "Generally it is much better to use unchecked conversion, which has no
 > requirements on alignment of the input data (the compiler must do the
right
 > thing, e.g. make a copy, regardless of alignments)."

Sorry, what I meant here was that *if* the compiler accepts the UC, it
must do the right thing (although I guess you can argue the contrary
if you are so inclined). 13.9(6-10) is about UC's that all compilers
must accept. GNAT accepts far more.

If you are asking "how can I do this in a manner that is 100% guaranteed
to be portable", the answer is that you can't.

What I said was definitely true of GNAT. In GNAT, we simply do a copy
if the alignment is not the same.

Certainly there is no reason in the world for 13.9(7) as it is written,
it should clearly be S'Alignment >= Target'Alignment. That's just a
(very unimportant) bug in the RM. The case of
S'Alignment < Target'Alignment is a little trickier, since clearly
you cannot return by reference in this case. But the return by
reference is only a permission anyway, and it would seem absurd
for a compiler to do the wrong thing in this case. I would guess that
in practice all compilers will accept this case and do the right thing
(make a copy). In the case of a scalar, likely a copy will be made
in any case.

Certainly I would expect a compiler to reject this case if it did
not do it right, rather than blindly assume and do the wrong thing.

It's interesting to note that Ada 83 had no statement about alignment,
but them it allowed any UC to be rejected. However, in Ada 83, it would
definitely be improper to place restrictions based on alignment and
not to reject the usage (i.e. an Ada 83 compiler could not just do
the wrong thing here silently. The fact that 13.9(11) can be read to
say that Ada 95 compilers can do this silent wrong treatment is probably
not really intended, given the history here. Perhaps this should be
brought to the attention of the ARG (feel free to do so if you like),
but I think it can probably remain moot, since I doubt there is an
issue in practice.

****************************************************************

From: Randy Brukardt
Sent: Friday, November 12, 2004  11:53 AM

Christoph Grein quotes Robert Dewar as saying:

> It's interesting to note that Ada 83 had no statement about alignment,
> but them it allowed any UC to be rejected. However, in Ada 83, it would
> definitely be improper to place restrictions based on alignment and
> not to reject the usage (i.e. an Ada 83 compiler could not just do
> the wrong thing here silently. The fact that 13.9(11) can be read to
> say that Ada 95 compilers can do this silent wrong treatment is probably
> not really intended, given the history here. Perhaps this should be
> brought to the attention of the ARG (feel free to do so if you like),
> but I think it can probably remain moot, since I doubt there is an
> issue in practice.

It's well known that 13.9(11) is way too broad; this was one of several
topics of discussion during the work on AI-167. We, however, were unable to
reach any consensus on what this should say. I have to admit that I am
unenthusiastic about again wading into that mess.

My personal opinion is that the compiler should either do the right thing or
reject the instantiation, with the single exception of cases involving types
with parts of access types. In that case, there can be no real definition of
what the "right thing" is, so it should be allowed with the "abnormal"
consequence.

The trouble is, enumerating all of the possibilities would be both
exhausting and controversial. So, it probably is better to let the
marketplace encourage vendors to do the right thing.

****************************************************************

Questions? Ask the ACAA Technical Agent