J3/02-102 Date: 7 Dec 2001 To: J3 From: R. Maine Subject: Changes to list of unresolved issues The following are changes made to the list of unresolved issues. These changes are reflected in 02-011 and in the J3 notes of 02-007. These changes add 11 new issues, resolve 2, and change 0. This makes a total of 356 issues, 337 of which have been resolved, and 19 of which remain. I. Resolved issues Paper 01-364r1 resolved issues 319 and 336. II. Changed unresolved issues The LaTeX conversion of 01-007r4 acidentally changed issue 344 to a regular note (10.13) instead of a J3 note. I changed it back to a j3 note (but it wouldn't surprise me to find that a paper from this same meeting resolves it, making this moot). III. New unresolved issues paper 01-363r2 issue 346 - USE only in ISO_C_BINDING Paper J3/01-363R2 completely reversed the previous specification on the matter of additional public entities in the ISO_C_BINDING module. That's ok, but.... I find it odd that not a single one of the examples in the standard follows the recommendation now stated here. If we believe in this recommendation, we should follow it. If we find that too annoying to do, then....draw your own conclusion. While cross-checking this question, I don't seem to have found whether we even addressed the question for the IEEE modules. Perhaps we should. The first para of clause 14 says that it is processor-dependent which of the named constants in IEEE_FEATURES is provided, but I can't find anything about whether there might be additional public names in any of the IEEE modules. Later. Oh, I see that paper 01-361r2 added something in 13.8 to cover the IEEE modules, so that part might now be ok. issue 347 - Interop with procedure arguments Paper J3/01-363r2 added the above phrase about dummy procedure arguments. Either I'm missing something or this addition was done without adequate attention to integration. A dummy procedure can't have the VALUE attribute, so apparently it would fall under item 6 below. Can anyone explain to me what item 6 even means in such a case? Don't forget to cover the case of subroutines (which don't have a type). This is probably solvable (though I suspect it will take quite a few more words). But I'm a liitle concerned to see us adding integration problems instead of solving them. This being integration with something 3 lines below isn't that awfully obscure. Perhaps I'm just misreading this. paper 01-355r3 issue 348 - PRIVATE accessibility Paper 01-355r3 claimed to have clarified the first sentence of the above paragraph about the accessibility attribute. However, it ``clarified'' it to make it self-contradictory. If an identifier is accessible in a module by USE association, then it obviously *IS* accessible outside of the module; indeed it was defined outsize of the module. paper 01-373r2 issue 349 - processor-dependent order Paper 01-373r2 added the above "processor-dependent order" replacing the prior "any order". However, this makes no sense as written. The processor doesn't determine the order of the program units. The processor might place requirements on what the order has to be (namely that modules must be processed before they are used), but that's not what this says. Even if we grant that reading of these words, this apparently innocuous wording change introduces a major incompatability and portability problem relative to all prior standards. The note below, which prompted this change, refers only to requiring modules to be processed first. The change to the normative text, however, is *FAR* broader. It implies that a processor might, for example, require that the program units be in alphabetical order. Do we really want to explicitly give processors permission to invent such spurious incompatibilities, with not even a hint as to what constitutes a reasonable expectation? paper 01-385r1 issue 350 - selector not present Shouldn't the above requirement that the selector be present be mentioned in 12.4.1.6? paper 01-394r1 issue 351 - boz and REAL The above expression for the result of boz arguments to REAL does not give a reasonable result for anything other than default real. The INT(A) gives a default integer result, which then doesn't TRANSFER reasonably to anything other than a default real. If I may make a suggestion, perhaps we should use a different descriptive model. We seem to be somewhat unable to decide on what a boz actually is. I've been assuming that a boz constant was of type integer. They are, after all, described in the section on integer types. But on closer reading, I don't see that we actually say they are of type integer. We do say in a few places that they are interpreted as if they were, but we don't say that they actually are. The edits of paper 01-394r1 clearly don't consider boz literals to actually be of type integer - if so, it would be nonsense to say that the arguments to, for example the INT intrinsic, could be "of type integer, real, or complex, or a boz-literal-constant." Treating boz constants as integers is going to make it difficult to use them on intrinsic reals larger than the largest supported integer kind. Lots of processors have this situation. It is common for the largest supported integer to be 32 bits, yet have 64-bit reals. Some processors support 64-bit integers, but then many of those also support 128-bit reals. EVen if we stick to the integers, there is the problem of representing negative integers of the largest supported integer kind. Perhaps we should go ahead and describe boz literals as typeless. We do, after all, specifically limit them to situations where their type doesn't matter (and this is intentional). Perhaps that is too controversial; I offer it only as a suggestion. In any case, the existing words describe behavior that I'm pretty sure would be a surprise to everyone. paper 01-367r1 issue 352 - USE ONLY The above para in c.8.2.1 has high maintenance costs. :-) I tried to rewrite it, but gave up because I couldn't actually figure out which of several points it was trying to make. The usage of "present" is very misleading here. ONLY has no relationship to dummy arguments. And I really could not tell what the business of "every accessed identifier being present" was trying to say anyway. I thought at first it was trying to say that the source of every accessed entity was explicitly declared. These words say absolutely nothing like that, but that would at least connect to the conclusion in the following sentence. I almost made that change before it occured to me that one might imagine a benefit to "every accessed entity appearing", even though that benefit is not the one implied by the following sentence. At this point I gave up. On the more trivial side, I suspect that the "each one" is intended to modify "identifiers", but as written it modifies "program units", which makes little sense. Also, it is slightly jarring to start with "An additional benefit of using the ONLY specifier", when none of the preceding stuff referred to the ONLY specifier by that term. paper 01-362r2 issue 353 - Inquiry functions I made the mistake of reading the definition of "inquiry function" given in 13.1 and cited in 14.8. The usage in section 14 does not match this definition. There are cases where it is vague, and others where it is just wrong. It is not clear to me whether it is best to broaden the definition or to reclassify some functions. The vagueness arises from the use of the term "principal" argument". That term is defined nowhere in the standard. The only use of it is in this definition of "inquiry function" (and in the same definition in the glossary). I therefore assume that the normal English definition applies, but it is a bit vague. In c13, it is mostly clear. An interpretation as either the first or the most important argument likely gives the same result. Things are a little vague for associated, same_type_as, and extends_type_of, but I can't argue that it is wrong, and the argument descriptions in those intrinsics do at least give some details. But in c14, some of the arguments that need not be defined are not the first argument, and are also at least arguably not the most important, thus making it pretty hard to justify that the label "principal" argument is sufficient identification. For example, in IEEE_SUPPORT_FLAG and IEEE_SUPPORT_ROUNDING, the X argument is the second one and is optional. I don't see how one can justify the identification of that as the "primary argument". This is vague at best (and I'd say that description was generous). For IEEE_SUPPORT_HALTING, it is not vague. There is only one argument, so it must be the principal one. But it clearly does need to be defined. Let me take this opportunity to note that we have nothing comparable to the 3rd para of 13.2 (about intent(in)) in section 14. It can be deduced from the statement that all the functions are pure, but we felt it necessary to spell this out in c13, so I'm not sure why not here. That's not an error, so wouldn't have justified an unresolved issue on its own, but as long as I'm here... paper 01-364r1 issue 354 - Scoping unit containing an object What scoping unit is the one that "contains an object"? This term is used in 16.2.4, but its definition is unclear. If this is intended to mean the scoping unit where an object is declared, then that would imply that the bindings with this as their scope were subject to the rules of use association, including such things as "use only" and renaming. Is that intended? If so, you could have an object accessible without these bindings being accessible. If this is intended to mean any scoping unit where the object is accessible, then the bindings would be accessible by their original identifiers anywhere that the object was accessible, but it seems to me that the bindings might also be accessible by another identifier through USE renaming. It is not at all clear to me whether the intention is one of these two interpretations or something else. The sentence also has grammatical number problems in that "the scoping unit" implies that there is only one (not one per object - one total). I could fix that aspect of the wording if I figured out what was intended technically, but I can't decipher the technical intent. paper 01-399 issue 355 - EOR= specifier paper 01-399 deleted the lead-in to the numbered list in the section on the EOR= specifier. Something to replace it is needed. I probably could have drafted something, but I've spent enough time on this. There are presumably conditions under which the list applies. It seems unlikely that it happens for every statement (even non-I/O ones). It seems equally unlikely that the conditions are those mentioned in the new version of the para before it (insomuch as that para says that execution terminates in those condistions). from an email issue 356 - PAD= for internal files Bob Corbett noted in an email that the above para in 9.5.4.4.2 essentially says that pad mode is ignored for internal reads. I suspect this wording was left over from when we had no way to specify the pad mode for internal reads. Now that we have such a way to specify the pad mode, it would be most irregular, confusing, and probably contradictory of other words in the standard, to ignore it. Probably this spot just got missed in the papers allowing more general pad mode specification. I was tempted to just strike the ``or during input from an internal file'', but I'm not sure that we call input from internal files either advancing or nonadvancing. Decided the fix is best left to J3.