AI22-0085-1

!standard 3.5.2(4/5)                                         23-12-07  AI22-0085-1/01

!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 work item 23-12-07

!status received 23-12-07

!priority Low

!difficulty Easy

!subject Various presentation issues

!summary

Make a number of presentation improvements.

!issue

(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.

!recommendation

(See summary.)

!wording

Modify 3.5.2(4/5):

The predefined type Wide_Wide_Character is a character type whose values correspond to {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.

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 all ceiling priorities in subrange System.Priority{'Range up} 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.

!discussion

(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 concievably 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.]

(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.

!ACATS test

None should be needed, these are only presentation changes -- no semantic change is intended.

!appendix

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.