Closed ARG-Editor closed 1 year ago
sttaft
commented
1 year ago I agree with your recommended fixes, but I would like to see the suggested wording all in one place, rather than the series of edits given above. I presume this will appear in the updated AI itself.
ARG-Editor
commented
1 year ago I've updated the AI. I ended up switching back to the "different declarations" requirement, since this AI is supposed to be allowing this check to be made in more places. Since the existing check had the "different declarations" requirement, changing it to a "user-specified" requirement instead would likely make additional work for implementations (in particular, the ones that tried to do the right thing in the first place; implementations that didn't try will clearly need some work now that there are ACATS tests). The use case for declarations elaborated multiple times is weak; it isn't worth forcing a change on implementors for it (even if the "user-specified" requirement is more in-line with the usage and probably is easier to implement).
Randy.The revised AI was approved at the ARG's November 2022 meeting.
Niklas Holsti identified several issues in his WG 9 review of AI22-0029-1. WG 9 sent that AI back to the ARG to fix those issues. I'll summarize and expand on the issues in this issue, and propose some solutions.
There are two different groups of issues, one mainly technical and one mainly editorial. Let me start with the group of editorial issues since they're more localized.
The proposed wording for 13.3(75.1/5) starts:
If both S and T exist in a given partition ...
Niklas noted that this wording never identifies what S and T are (while the previous wording clearly talked about tagged types). One might think that these have something to do with the S and T defined in 13.3(74/1), but that would be wrong, as that S is a subtype of T, whereas in this rule S and T are separate types.
So this rule needs to clearly identify what it is talking about, and, in order to avoid confusion, use some letters other than S and T (at a minimum S needs to be different, but given how this rule is applied, it is better to change both letters).
Ergo, I suggest this wording be changed to:
If two tagged types J and K both exist in a given partition, and ...
(changing all of the other occurrences of S and T in the proposed wording to J and K, respectively).
Niklas also notes that there is no exception for two elaborations of the same declaration in 13.3(75.1/5), which contradicts the modified AARM note after 13.3(76.e). That note says:
Note that if such identical tags are used for two different elaborations of the same declaration, they cannot raise Program_Error; the check that requires different External_Tags specifically excludes types that come from the same declaration.
But there is nothing in 13.3(75.1/5) that says anything about the declaration of the types. The permission of 13.3(76.1/3) does mention different declarations, but that has a different purpose and is unrelated to the actual required check.
My recollection was that we had intended the check only to apply when at least one of the types is user-specified. The !discussion starts with that statement, and that would be sufficient to deal with the case of default external tags for multiple elaborations of the same declaration (in that case, there would be no check since both tags are defaulted).
Note that it is important that the default external tag never cause Program_Error to be raised. One might not even be using any operations that use the External_Tag, and it would be nasty to have the program terminated simply because of a problem with that tag.
On the other hand, it is important the External_Tag be unique when it is used in the program, since the point of the construct is to allow streaming of tagged types between multiple related programs. That does not work reliably when multiple types have the same External_Tag. We can assume that programs that need to do tagged type streaming in this way are the only ones that would user-specify an external tag.
So, to fix the identified problem, we should redo the start of the wording as follows:
If two tagged types J and K both exist in a given partition, J'External_Tag is user-defined, and ...
This also requires a tweak to the AARM Note mentioned above:
Note that if such identical tags are used for two different elaborations of the same declaration, they cannot raise Program_Error; the check that requires different External_Tags requires one of the External_Tags to be user-defined (these are both chosen by default).
Note that this means that giving a user-specified External_Tag for a declaration that might be elaborated more than once will always raise Program_Error if the multiple such types exist at the same time. This seems like a good thing, since streaming using such a tag would not work reliably (remember, we are assuming that a user-specified tag will be used for streaming).
We don't change the permission of 13.3(76.1/3), since we don't want to reject a program that never actually creates multiple tagged types from a single declaration (even if there is a possibly that it might). For instance, a subprogram that defines a tagged type with a user-specified External_Tag could be called from multiple tasks simultaneously; but if the code prevents that somehow (via locking or other technique), there would not be a problem.
An alternative to the fix outlined above would explicitly exclude the runtime check for External_Tags that come from the same declaration. This seems like a worse solution for two reasons: (1) As noted above, streaming (the intended use of External_Tags) won't work as expected if there is an undetected conflict. (2) In the case of an implementation using a runtime registration scheme, the implementation of the check appears harder if one needs to exclude tags from the same declaration as opposed only only checking when one of the tags is user-defined. For either of these rules, some additional information would be need to be passed to the runtime tag manager (which would make the actual check). For the user-defined version of the check, one would only need a single extra bit to specify whether or not a specific tag is user-defined. But for the "different declaration" version of the check, some sort of unique identifier for each declaration would be required. The latter seems like an additional complication that may or may not exist in an implementation.