Version 1.7 of ais/ai-00256.txt

Unformatted version of ais/ai-00256.txt version 1.7
Other versions for file ais/ai-00256.txt

!standard 13.11.01 (01)          02-07-19 AI95-00256/05
!standard A.12.01 (30)
!standard G.02.02 (03)
!standard 7.06.01 (16)
!standard 7.04 (09)
!standard 10.02 (09)
!class binding interpretation 01-02-12
!status work item 01-02-12
!status received 01-02-12
!qualifier Omission
!priority Low
!difficulty Easy
!subject Various wording changes to the standard
!summary
(Note: This AI contains various wording changes that ought to be made to the standard for which there is expected to be no opposition to the change. The intent is that this AI will only be processed when a Corrigendum or Amendment is about to be issued.)
1) The value of the Size_In_Storage_Elements is the maximum value that could be requested by the implementation.
2) Ada.Streams.Read (and Write) without an index parameter read (or write) at the current index if the file supports positioning.
3) The rule of 3.5.8(2/1) applies in G.2.2(3) as well. (Otherwise the RM is inconsistent.)
4) The first sentence of 7.6.1(16/1) applies to all calls to Adjust other than those in assignment statements.
5) The reference in 7.4(9) should be to 13.14.
6) 10.2(9) should say "names" rather than "mentions".
!question
1) What is the value for Size_In_Storage_Elements?
13.11.1(3) states that:
"S'Max_Size_In_Storage_Elements denotes the maximum value for Size_In_Storage_Elements that will be requested via Allocate for an access type whose designated subtype is S."
This seems to imply that the upper bound depend on the execution of the program. That's because this wording doesn't specify a conservative upper bound, nor a guess or an approximation. Shouldn't this say "that could be requested?" (Yes.)
2) Where do Ada.Streams.Stream_IO.Read (and Write) without an index parameter read (or write) if the file supports positioning? (At the current index.)
Nowhere in A.12.1 is this specified. Defect Report 8652/0055 says that the intent is that stream files with positioning act like Dirct_IO files. Is it OK for an implementation to ignore the current index of a stream file? (No.)
3) The Technical Corrigendum fixes 3.5.8(2), which links 'Digits and 'Model_Mantissa. But it does not fix G.2.2(3), which contains essentially the same formula. Was this intended? (No.)
4) The rule of 7.6.1(16/1) defines what happens for assignment statements and for initializations, but what about other kinds of assignment operations (such as generic object creation, 12.4(11))? Shouldn't they be treated the same as initializations? (Yes.)
5) 7.4(9) says: "The completion of a deferred constant declaration shall occur before the constant is frozen (see 7.4)."
The recursive reference from 7.4 to itself is incorrect. Should this be 13.14? (Yes.)
6) The AI-00180 says that "mentioned" is used "informally" in 10.2(9); it it not intended to mean the technical term "mentioned". Should this be reworded to avoid the use of the technical term. (Yes.)
!recommendation
(See summary.)
!wording
(See corrigendum.)
!discussion
1) The intent of the Size_In_Storage_Elements is that it supplies an upper bound on the memory that will be requested from Allocate. Certainly, there was no intent that the value depend on the execution of the program. Thus, we adjust the wording to say clearly what was meant.
2) Defect Report 8652/0055 make it clear that the model of stream files with positioning is to be the same as Direct_IO files. Unfortunately, the wording with that Defect Report failed to say where Read and Write without an index parameter read or write. Compare A.12.1(30) to A.8.5(3) to see the missing text.
3) Defect Report 8652/0004 clearly states that the intent of the language is as specified in 3.5.8(2/1). The failure to change the related paragraph G.2.2(3) as well is just an oversight.
4) Defect Report 8652/0024 clearly differentiates between "assignment statements" and "initialization by assignment". It never discusses anything that isn't one or the other; the authors appearently thought that there were no other possibilities. All of the other cases of assignment operations are very similar to "initialization", and thus should be treated the same way; this was the expectation of the authors of the previous report. Thus, the wording of the first sentence is too narrow, and should be broadened.
5) Certainly a reference from a clause to itself is in error. The wording suggests that the reference is to the freezing rules, which is clause 13.14.
6) The AARM contains a note essentially to ignore the use of "mentioned" in this rule. That cannot be clear; it would be better to fix the rule in the Amendment.
!corrigendum 7.04(09)
Replace the paragraph:
The completion of a deferred constant declaration shall occur before the constant is frozen (see 7.4).
by:
The completion of a deferred constant declaration shall occur before the constant is frozen (see 13.14).
!corrigendum 7.06.01(16)
Replace the paragraph:
by:
!corrigendum 10.02(09)
Replace the paragraph:
The order of elaboration of library units is determined primarily by the elaboration dependences. There is an elaboration dependence of a given library_item upon another if the given library_item or any of its subunits depends semantically on the other library_item. In addition, if a given library_item or any of its subunits has a pragma Elaborate or Elaborate_All that mentions another library unit, then there is an elaboration dependence of the given library_item upon the body of the other library unit, and, for Elaborate_All only, upon each library_item needed by the declaration of the other library unit.
by:
The order of elaboration of library units is determined primarily by the elaboration dependences. There is an elaboration dependence of a given library_item upon another if the given library_item or any of its subunits depends semantically on the other library_item. In addition, if a given library_item or any of its subunits has a pragma Elaborate or Elaborate_All that names another library unit, then there is an elaboration dependence of the given library_item upon the body of the other library unit, and, for Elaborate_All only, upon each library_item needed by the declaration of the other library unit.
!corrigendum 13.11.01(03)
Replace the paragraph:
Denotes the maximum value for Size_In_Storage_Elements that will be requested via Allocate for an access type whose designated subtype is S. The value of this attribute is of type universal_integer.
by:
Denotes the maximum value for Size_In_Storage_Elements that could be requested by the implementation via Allocate for an access type whose designated subtype is S. The value of this attribute is of type universal_integer.
!corrigendum A.12.01(30)
Replace the paragraph:
The procedures Read and Write are equivalent to the corresponding operations in the package Streams. Read propagates Mode_Error if the mode of File is not In_File. Write propagates Mode_Error if the mode of File is not Out_File or Append_File. The Read procedure with a Positive_Count parameter starts reading at the specified index. The Write procedure with a Positive_Count parameter starts writing at the specified index.
by:
The procedures Read and Write are equivalent to the corresponding operations in the package Streams. Read propagates Mode_Error if the mode of File is not In_File. Write propagates Mode_Error if the mode of File is not Out_File or Append_File. The Read procedure with a Positive_Count parameter starts reading at the specified index. The Write procedure with a Positive_Count parameter starts writing at the specified index. For a file that supports positioning, Read without a Positive_Count parameter starts reading at the current index, and Write without a Positive_Count parameter starts writing at the current index.
!corrigendum G.2.2(3)
Replace the paragraph:
Yields the number of digits in the mantissa of the canonical form of the model numbers of T (see A.5.3). The value of this attribute shall be greater than or equal to Ceiling(d log(10) / log(T'Machine_Radix)) + 1, where d is the requested decimal precision of T. In addition, it shall be less than or equal to the value of T'Machine_Mantissa. This attribute yields a value of the type universal_integer.
by:
Yields the number of digits in the mantissa of the canonical form of the model numbers of T (see A.5.3). The value of this attribute shall be greater than or equal to
ceiling(d * log(10) / log(T'Machine_Radix)) + g
where d is the requested decimal precision of T, and g is 0 if Machine_Radix is a positive power of 10 and 1 otherwise.
In addition, it shall be less than or equal to the value of T'Machine_Mantissa. This attribute yields a value of the type universal_integer.
!ACATS test
1) The existing test CDB0A02 tests Size_In_Stream_Elements.
2) Test CXAC005 (which checks the objective for 8652/0055) also checks this rule.
3) The ARG voted to not test the change to 3.5.8(2) (because it applies to very few machines), and that vote applies here as well.
!appendix

From: Randy Brukardt
Sent: Monday, January 15, 2001 5:41 PM

There is a hole in the RM in that it never says that Read and Write
without index parameters actually Read or Write at the current index.
(Compare A.12.1(30) to A.8.5(3).) Certainly, the intent of AI-26 was that
the model of positionable stream files is similar to Direct_IO files. It
certainly would be odd if that didn't include the location of Reading and
Writing. Probably a sentence like the following needs to be added to the RM:

    "For a file that supports positioning, Read without a Positive_Count
parameter starts reading at the current index, and Write without a
Positive_Count parameter starts writing at the current index."

I would assume the above is non-controversial, but since quite a few
compilers ignore it, perhaps I'm wrong.

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

From: Pascal Leroy
Sent: Thursday, January 18, 2001 8:09 AM

I am noticing that DR 0004 fixes 3.5.8(2), which links 'Digits and
'Model_Mantissa.  It seems that it should also have fixed G.2.2(3), which
contains essentially the same formula.

Oh well...

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

From: Tucker Taft
Sent: Wednesday, March 21, 2001 9:47 PM

> |16/1 {For an Adjust invoked as part of the initialization of a controlled
> |      object, other adjustments due to be performed might or might not be
> |      performed, and then Program_Error is raised.  During its propagation,
> |      finalization might or might not be applied to objects whose Adjust
> |      failed.}  For an Adjust invoked as part of an assignment operation,
> |      any other adjustments due to be performed are performed, and then
> |      Program_Error is raised.
>
> > [STT]  The second sentence should read:
> > >      For an Adjust invoked as part of an assignment *statement*, ...
> >
> > I'll add this to the "Wording changes no one will argue with" AI.
>
> Au contraire!?
> Tuck's refinement leaves holes, no?--in that his syntactic denotation
> is less inclusive than "assignment operation outside of initialization"
> --e.g., 12.4(11)'s allowance for adjustment!?  Is this right/safe/desired?

The assignment in 12.4(11) is an assignment as part of
initialization (of a generic formal in obj), and should follow the
rules for adjusts as part of initialization.

Assignment statements are special because they occur after the
target object has been fully initialized, and if they fail, the target object
is still going to be fully finalized, so you don't want to stop
adjusting just because one component's adjust fails.

Of course, I know that 12.4(11) is an initialization, and maybe you
know it too, but is it clear from the RM?  I'm not sure.

Paragraph 16/1 might be better put in terms of "adjusts as part of
assignment operation other than an assignment statment," and "adjusts
as part of the assignment operation of an assignment statement."
What a mouthful...

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

From: Randy Brukardt
Sent: Thursday, March 22, 2001 11:42 AM

My main concern at this point is to get "correct" wording, not necessarily
"best" wording.

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

!topic Recursive reference in RM95
!reference RM95-7.4(9)
!from Adam Beneschan 02-28-02
!discussion

7.4(9) says: "The completion of a deferred constant declaration shall
occur before the constant is frozen (see 7.4).

I suspect the recursive reference from 7.4 to itself is incorrect.
Should this be 13.14?

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

Questions? Ask the ACAA Technical Agent