AI22-0085-1
!standard 3.5.2(4/5) 24-02-17 AI22-0085-1/04
!standard 4.3.3(20.3/6)
!standard 4.3.3(20.4/6)
!standard 4.3.5(33/5)
!standard D.2.4(11/3)
!class presentation 23-12-07
!status Amendment 1-2022 23-12-14
!status WG9 Approved 24-06-10
!status ARG Approved 11-0-0 23-12-14
!status work item 23-12-07
!status received 23-12-07
!submitter Randall Brukardt, Christoph Grein, and Nicole Mazzuca
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Various presentation issues
Make a number of presentation improvements.
(1) AI22-0006-1 rewrites 4.3.3(20.3) and (20.4). In particular, "produced" is changed to "conditionally produced". When "conditionally produced" appears in 4.3.3(20.4), there are several cross-references. Our usual policy is to have cross-references on the first usage of a term in a subclause, but here they are on what is now the second usage.
(2) D.2.4(11/3) starts:
Since implementations are allowed to round all ceiling priorities in subrange System.Priority to System.Priority'Last (see D.3), an ...
This can be parsed two ways (using brackets to illustrate grouping):
Since implementations [are allowed to round all ceiling priorities in [subrange System.Priority to System.Priority'Last] (see D.3)], an ...
or
Since implementations [are allowed to round all ceiling priorities in subrange System.Priority][ to System.Priority'Last] (see D.3)], an ...
The first parsing is nonsense, so a reader that lands on it would be very confused.
(3) The first sentence of 3.5.2(4/5) is:
The predefined type Wide_Wide_Character is a character type whose values correspond to the 2147483648 code points of the ISO/IEC 10646:2020 character set.
But 10646 only defines UCS code points in the range 0 .. 16#10FFFF#. Thus, there are only
16#110000# code points, or 1114112.
(4) 4.3.5(33/5) talks about the Add_Indexed procedure. This is the only mention of Add_Indexed in the RM.
(See summary.)
Modify 3.5.2(4/5):
The predefined type Wide_Wide_Character is a character type whose values [correspond to]{include all of} the [2147483648 ]code points of the ISO/IEC 10646:2020 character set. Each of the graphic_characters has a corresponding character_literal in Wide_Wide_Character. The first 65536 values of Wide_Wide_Character have the same character_literal or language-defined name as defined for Wide_Character. {Wide_Wide_Character has 2**32 distinct values.}
Modify 4.3.3(20.3/6):
Each iterator_specification is elaborated (in an arbitrary order) and an iteration is performed solely to determine a count for the number of values conditionally produced by the iteration{ (see 5.5 and 5.5.2)}; all of these counts are combined to determine the overall length of the array, and ultimately the bounds of the array (defined below);
Modify 4.3.3(20.4/6):
A second iteration is performed for each of the iterator_specifications, in the order given in the aggregate, and for each value conditionally produced by the iteration[ (see 5.5 and 5.5.2)], the associated expression is evaluated, its value is converted to the component subtype of the array type, and used to define the value of the next component of the array starting at the low bound and proceeding sequentially toward the high bound. As part of this second iteration, a check is made that it results in the same number of elements as the first iteration; Constraint_Error is raised if this check fails. This check is performed before any attempt to access any nonexistent element of the array object.
Modify 4.3.5(33/5):
[Editor's note: AARM 4.3.5(92.h/6) also mentions this non-existent routine. Fix that as well.]
Modify D.2.4(11/3):
Since implementations are allowed to round {up to System.Priority'Last} all ceiling priorities in subrange System.Priority{'Range}[ to System.Priority'Last] (see D.3), an implementation may allow a task of a partition using the Non_Premptive_FIFO_Within_Priorities policy to execute within a protected object without raising its active priority provided the associated protected unit does not contain any subprograms with aspects Interrupt_Handler or Attach_Handler specified, nor does the unit have aspect Interrupt_Priority specified. When the locking policy (see D.3) is Ceiling_Locking, an implementation taking advantage of this permission shall ensure that a call to Yield_to_Higher that occurs within a protected action uses the ceiling priority of the protected object (rather than the active priority of the task) when determining whether to preempt the task.
(1) This problem was noted when AI22-0006-1 was applied to the draft RM. Since AI22-0006-1 is already WG 9 approved, we cannot make this change to it as an Editorial Review change. So we have to do it here.
(2) We make a pair of minor tweaks to the wording. In particular, the insertion of "up" should make it clear that we're not talking about a pair of range bounds.
(3) We remove the number, since the 10646 limit on the number of code points seems rather arbitrary and conceivably could be changed someday. And the number of code points doesn't seem relevant for the definition of Wide_Wide_Character.
[Editor's note: Is this actually true? Arguably, the number is defining the value of Wide_Wide_Character'Last. That could matter to some code, and certainly would matter to the result of 'Valid for some bit patterns. If this is deemed an issue, we'll have to split this into a Binding Interpretation in order to clearly define Wide_Wide_Character'Last. Note that it is not currently clear if Wide_Wide_Character'Last'Pos = 2**31-1 or 2**32-1, and this change would add 16#10FFF# to the mix. This eventually was handled in AI22-0095-1.]
(4) Add_Indexed clearly should be Assign_Indexed.
Bizarrely, AI22-0031-1 makes this mistake throughout. Luckily no RM wording is involved. It's surprising that the AI got all the way through ARG review, editorial review, and WG 9 review without this obvious mistake being detected. Since this AI is a WG 9 approved AI, we can't change the contents. Hopefully this note is sufficient to prevent any future questions on this topic.
@drepl
The predefined type Wide_Wide_Character is a character type whose values correspond to the 2147483648 code points of the ISO/IEC 10646:2020 character set. Each of the @fa{graphic_character}s has a corresponding @fa{character_literal} in Wide_Wide_Character. The first 65536 values of Wide_Wide_Character have the same @fa{character_literal} or language-defined name as defined for Wide_Character.
@dby
The predefined type Wide_Wide_Character is a character type whose values include all of the code points of the ISO/IEC 10646:2020 character set. Each of the @fa{graphic_character}s has a corresponding @fa{character_literal} in Wide_Wide_Character. The first 65536 values of Wide_Wide_Character have the same @fa{character_literal} or language-defined name as defined for Wide_Character. Wide_Wide_Character has 2**32 distinct values.
@drepl
@xhang{@xterms{1.}Each @fa{iterator_specification} is elaborated (in an arbitrary order) and an iteration is performed solely to determine a count for the number of values conditionally produced by the iteration; all of these counts are combined to determine the overall length of the array, and ultimately the bounds of the array (defined below);}
@dby
@xhang{@xterms{1.}Each @fa{iterator_specification} is elaborated (in an arbitrary order) and an iteration is performed solely to determine a count for the number of values conditionally produced by the iteration (see @ref{5.5} and @ref{5.5.2}); all of these counts are combined to determine the overall length of the array, and ultimately the bounds of the array (defined below);}
@drepl
@xhang{@xterms{2.}A second iteration is performed for each of the @fa{iterator_specification}s, in the order given in the @fa{aggregate}, and for each value conditionally produced by the iteration (see @ref{5.5} and @ref{5.5.2}), the associated @fa{expression} is evaluated, its value is converted to the component subtype of the array type, and used to define the value of the next component of the array starting at the low bound and proceeding sequentially toward the high bound. As part of this second iteration, a check is made that it results in the same number of elements as the first iteration; Constraint_Error is raised if this check fails. This check is performed before any attempt to access any nonexistent element of the array object.}
@dby
@xhang{@xterms{2.}A second iteration is performed for each of the @fa{iterator_specification}s, in the order given in the @fa{aggregate}, and for each value conditionally produced by the iteration, the associated @fa{expression} is evaluated, its value is converted to the component subtype of the array type, and used to define the value of the next component of the array starting at the low bound and proceeding sequentially toward the high bound. As part of this second iteration, a check is made that it results in the same number of elements as the first iteration; Constraint_Error is raised if this check fails. This check is performed before any attempt to access any nonexistent element of the array object.}
@drepl
@xinbull{if the @fa{aggregate} is a @fa{positional_container_aggregate}, the lower bound is the low bound of the subtype of the key parameter of the Add_Indexed procedure, and the upper bound has a position number that is the sum of the position number of the lower bound and one less than the number of @fa{expression}s in the @fa{aggregate};}
@dby
@xinbull{if the @fa{aggregate} is a @fa{positional_container_aggregate}, the lower bound is the low bound of the subtype of the key parameter of the Assign_Indexed procedure, and the upper bound has a position number that is the sum of the position number of the lower bound and one less than the number of @fa{expression}s in the @fa{aggregate};}
@drepl
Since implementations are allowed to round all ceiling priorities in subrange System.Priority to System.Priority'Last (see @ref{D.3}), an implementation may allow a task of a partition using the Non_Premptive_FIFO_Within_Priorities policy to execute within a protected object without raising its active priority provided the associated protected unit does not contain any subprograms with aspects Interrupt_Handler or Attach_Handler specified, nor does the unit have aspect Interrupt_Priority specified. When the locking policy (see @ref{D.3}) is Ceiling_Locking, an implementation taking advantage of this permission shall ensure that a call to Yield_to_Higher that occurs within a protected action uses the ceiling priority of the protected object (rather than the active priority of the task) when determining whether to preempt the task.
@dby
Since implementations are allowed to round up to System.Priority'Last all ceiling priorities in subrange System.Priority’Range (see @ref{D.3}), an implementation may allow a task of a partition using the Non_Premptive_FIFO_Within_Priorities policy to execute within a protected object without raising its active priority provided the associated protected unit does not contain any subprograms with aspects Interrupt_Handler or Attach_Handler specified, nor does the unit have aspect Interrupt_Priority specified. When the locking policy (see @ref{D.3}) is Ceiling_Locking, an implementation taking advantage of this permission shall ensure that a call to Yield_to_Higher that occurs within a protected action uses the ceiling priority of the protected object (rather than the active priority of the task) when determining whether to preempt the task.
None should be needed, these are only presentation changes -- no semantic change is intended.
From: Nicole Mazzuca
Sent: Tuesday, April 5, 2022 7:02 PM
Hi!
I was just reading the Ada standard when I noticed what I consider to be an error in the specification of character types. 3.5.2(4/3) currently reads “The predefined type Wide_Wide_Character is a character type whose values correspond to the 2147483648 code points of the ISO/IEC 10646:2011 character set.” (it reads the same in the draft standard except with ISO/IEC 10646:2011 replaced with ISO/IEC 10646:2017, and the paragraph number is now 3.5.2(4/5)).
I believe this to be incorrect; according to ISO/IEC 10646:2020 (I’m sorry, I can’t find an older standard but I’m certain that 2017 has the same wording), under section 3 “Terms and Definitions”, 3.9 – a code point is defined as a “value in the UCS codespace”, with a note: “Note 1 to entry – Code points in the UCS codespace are integer values. Throughout this document, UCS code points are cited in hexadecimal. UCS code points range from 0 to 10FFFF”. Basically, there are only 0x110000 code points, or 1114112. Wide_Wide_Character may allow values that are outside that range, but those are not code points.
Thanks!
From: Jeff Cousins
Sent: Saturday, April 9, 2022 2:04 PM
I think Nicole is correct. Does any one know otherwise?
From: Jean-Pierre Rosen
Sent: Saturday, April 9, 2022 11:59 PM
Agreed. Note that there were 2147483648 code points (or maybe half of that) in 10646 before the merging with Unicode, this may explain the statement.
From: Tucker Taft
Sent: Sunday, April 10, 2022 7:43 AM
I agree. The ISO 10646 standard does not currently take advantage of the full 31 bits available. It might be better to just remove the number, and say something like "all of the code points" because I could see them increasing it at some point.
!topic Since implementations are allowed to round all ceiling priorities in subrange
System.Priority[ to System.Priority'Last (see D.3)], an...
!reference Ada 2022 RM D.2.4(11/3) Draft 35
!from Grein 23-01-25
!discussion
Something si wrong there - either lower limit is missing or upper limit is nonsense.
From: Tucker Taft
Sent: Monday, January 30, 2023 3:50 PM
Can you clarify what you believe is wrong? The sentence is saying that for any priority value in the (sub)range of System.Priority (which is equivalent to saying any value in the range System.Priority'First .. System.Priority'Last), the implementation may treat it as though the programmer specified the maximum allowed value, namely System.Priority'Last.
From: Randy Brukardt
Sent: Monday, January 30, 2023 10:52 PM
Perhaps he is confused by the word "round"? This is not a conventional rounding operation (where one sets a value to the nearest value that is subject to some criteria). It's about setting all values in the range of Priority to a single value. I would have not described that as "rounding", it's more like "ignoring" the priority (since this makes all protected objects compatible with all
[non-interrupt] tasks).
OTOH, D.3 does use the word "round" to describe this operation, so the RM is consistent. And I suppose in cases other than the one described in D.2.4, it could actually act as rounding (when there are multiple ranges of priorities that are rounded to multiple values).
I don't really see a way to make this better without rewriting D.3, and that doesn't seem to be justified.
From: Jeff Cousins
Sent: Tuesday, January 31, 2023 7:50 AM
Depending on how you parse it in your head, it can read strangely. The commenter is parsing D.2.4(11/3) as
“
Since implementations are allowed to round
all ceiling priorities in subrange
System.Priority to System.Priority'Last
(see D.3), an...
“
as if “System.Priority to System.Priority'Last” is being referred to as a subrange.
It’s intended to be parsed as
“
Since implementations are allowed to round all ceiling priorities in subrange System.Priority
to System.Priority'Last
“
Maybe “Since implementations are allowed to round, to System.Priority'Last, all ceiling priorities that fall within subrange System.Priority” though I’m ok with it as it is, it doesn’t require as much turning your inside out as some of the LRM.
From: Christoph Grein
Sent: Tuesday, January 31, 2023 3:32 AM
> Since implementations are allowed to round all ceiling priorities in subrange
> System.Priority to System.Priority'Last (see D.3)], an...
Hu, for me it's obvious. System.Priority is a subrange, so it either is the subrange System.Priority'First to System.Priority'Last or simply the subrange System.Priority.
System.Priority to System.Priority'Last does not make sense to me at least.
From: Christoph Grein
Sent: Tuesday, January 31, 2023 3:37 AM
Oops, now I see my misreading:
All values within System.Priority are rounded to System.Priority'Last
I misunderstood as a subrange System.Priority .. System.Priority'Last which
does not make sense.
From: Jean-Pierre Rosen
Sent: Tuesday, January 31, 2023 3:46 AM
Maybe "up to System.Priority'Last" would be clearer...
From: Tucker Taft
Sent: Tuesday, January 31, 2023 1:46 PM
Agreed. Inserting the word "up" would help, as would adding an explicit 'Range:
Since implementations are allowed to round all ceiling priorities in
System.Priority'Range up to System.Priority'Last (see D.3)], ...
From: Christoph Grein
Sent: Wednesday, February 1, 2023 8:13 AM
Since implementations are allowed to round all ceiling priorities in
System.Priority'Range up to System.Priority'Last (see D.3)], ...
I think this wording is clearer. You know the RM is sometimes especially hard
to understand since its audience is mainly language lawyers, but we simple
software engineers have to understand it as well.