Version 1.2 of ais/ai-00221.txt

Unformatted version of ais/ai-00221.txt version 1.2
Other versions for file ais/ai-00221.txt

!standard 13.7 (15)          00-04-12 AI95-00221/02
!standard 13.7 (35)
!class binding interpretation 99-06-25
!status ARG Approved 8-0-0 00-03-31
!status work item 99-06-25
!status received 99-06-14
!priority Medium
!difficulty Easy
!subject Default_Bit_Order is static
!summary
System.Default_Bit_Order is a non-deferred, static constant.
!question
13.7(15) defines System.Default_Bit_Order as a deferred constant. This requires it to be nonstatic, and prevents its use in representation clauses. Was this intended? (No.)
!recommendation
(See summary.)
!wording
Replace the definition of Default_Bit_Order in 13.7(15) by:
Default_Bit_Order : constant Bit_Order := implementation-defined;
Add Default_Bit_Order shall be a static constant to 13.7(35).
!discussion
One of the purposes of Default_Bit_Order is to conditionalize representation clauses so that a single representation clause can be used. However, this use requires that Default_Bit_Order be a static constant. Unfortunately, Default_Bit_Order is defined with a deferred constant declaration, which can never be static.
!ACATS test
A test could be created to insure that Default_Bit_Order is static.
!corrigendum 13.07(15)
Replace:
Default_Bit_Order : constant Bit_Order;
by:
Default_Bit_Order : constant Bit_Order := implementation-defined;
!corrigendum 13.07(35)
Replace the paragraph:
See 13.5.3 for an explanation of Bit_Order and Default_Bit_Order.
by:
See 13.5.3 for an explanation of Bit_Order and Default_Bit_Order. Default_Bit_Order shall be a static constant.
!appendix

From: Tucker Taft
Sent: Monday, June 14, 1999 9:52 AM

Robert Dewar wrote:
>
> > One other little point, why on earth is Default_Bit_Order required to
> > be nonstatic, this seems a huge goof, since it is most obvious that you
> > might use this to conditionalize rep clauses.

Tucker Taft responded:

> Good point.  I suspect many package System's out there have the value
> of Default_Bit_Order given in the visible part, even though the
> manual pretty clearly indicates that it is supposed to be a
> deferred constant.  The ARG could easily rule that it should
> be a non-deferred constant.  Most of the other constants in System
> are non-deferred, even though they are similarly implementation-defined.
>
> Presumably you can use the 'Bit_Order attribute in some cases, though
> using it in a rep-clause for the record type itself would freeze it
> prematurely!  Another annoyance...

I think we should rule that Default_Bit_Order should be a non-deferred
constant.  I suspect it was unintentional that Default_Bit_Order
should be nonstatic.

Comments?

-Tuck

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

From: Randy Brukardt
Sent: Monday, June 14, 1999 12:04 PM

> Good point.  I suspect many package System's out there have the value
> of Default_Bit_Order given in the visible part, even though the
> manual pretty clearly indicates that it is supposed to be a
> deferred constant.

I for one never noticed that there was a difference between the declaration
of Default_Bit_Order and the other constants in System. I doubt that it is
obvious to most users, either. I certainly have no objection to making this
constant static, it probably will fix some portability problems (if users
depend on it).

                        Randy.

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

From: Robert A Duff
Sent: Monday, June 14, 1999 1:14 PM

> I think we should rule that Default_Bit_Order should be a non-deferred
> constant.  I suspect it was unintentional that Default_Bit_Order
> should be nonstatic.

I wrote that section, and as I recall, the only reason I made it a
deferred constant was to avoid having to write yet one more italicized
"implementation-defined".

We should rule that not only is the constant non-deferred, but also that
it is a *static* constant, which is the whole point of the change!

- Bob

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

From: Randy Brukardt
Sent: Monday, June 14, 1999 1:35 PM

> I wrote that section, and as I recall, the only reason I made it a
> deferred constant was to avoid having to write yet one more italicized
> "implementation-defined".

Humm, language design by sloth. Interesting technique! :-)

> We should rule that not only is the constant non-deferred, but also that
> it is a *static* constant, which is the whole point of the change!

I agree.

                        Randy.

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

From: Robert Dewar
Sent: Saturday, June 19, 1999 8:53 PM

<<We should rule that not only is the constant non-deferred, but also that
it is a *static* constant, which is the whole point of the change!
>>

Agreed, I am just going to go ahead and make this change in GNAT (note that
Greenhills currently makes this static, so this actually improves
consistency :-)

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

Questions? Ask the ACAA Technical Agent