J3/00-231 Date: 12 Jun 2000 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 00-011R2 and in the J3 notes of 00-007R2. These changes add 13 new issues and resolve 12. This makes a total of 282 issues, 203 of which have been resolved, and 79 of which remain. I. Resolved issues Paper 00-172r2 resolved issue 263. Paper 00-174r1 resolved issue 236. Paper 00-175r1 resolved issue 268. Paper 00-176r2 resolved issue 269. Paper 00-177 resolved issue 7. Paper 00-184r2 resolved issue 258. Paper 00-198r1 resolved issue 226. Paper 00-199r1 resolved issue 112. Paper 00-212 resolved issue 214. Paper 00-215 resolved issue 256. Paper 00-216 resolved issue 261. Paper 00-218r1 resolved issue 247. II. Changed unresolved issues paper 00-173r1 issue 262 - definition of intrinsic As discussed on the floor, paper 00-173r1 edited the definition of intrinsic on 2.5.7, but didn't fix the glossary. Thus rather that deleting the issue, I moved it to the glossary and revised it to read "The definition of intrinsic in 2.5.7 is now fixed so that it doesn't blatantly contradict other parts of the standard, but the above definition in the glossary still does. I also think that section 13 is a bit misleading in this regard. It talks as though it were describing all intrinsics. But its at least not blatantly wrong - just a bit misleading. I'd suggest a few words there. The definition in the glossary is just wrong (or anyway doesn't agree with how we use the term). paper 00-182r1 issue 266 changed as specified in the paper. paper 00-183r2, round to nearest issue 237 - rounding Modified as specified in the paper. And added the following The specification of the midpoint case for NEAREST in the 2nd para above is still circular. It says, in essence, that if the processor does IEEE roundingm then it is required to do IEEE rounding; if the processor doesn't do IEEE rouding, then it doesn't have to. As best as I can tell, the specification of NEAREST is completely equivalent to just saying that the choice at the midpoint is processor-dependent; we don't need to distinguish based on whether or not the processor does IEEE. The para beginning "On processors that support IEEE" adequately and completely covers the IEEE case. paper 00-215 issue 151 changed as specified in the paper. paper 00-219 issue 94 changed as specified in the paper. III. New unresolved issues paper 00-207 Added issues 270 and 271 as specified in the paper. paper 00-171r2, procedure pointers The issue added in the paper is numbered 272. Added the sentence 'Note that the above "ought to be" is not (yet?) a specification adopted by J3.' paper 00-176r1, pass_obj issue 273 - pass_obj I doubt that the phrase "same type as the type name" means what it says. I don't think a type name has a type. paper 00-211, is interoperable issue 274 - definition of BIND The above definition of the BIND attribute in 5.1.2.15 appears to be using terminology incorrectly. Note that this says that BIND specifies that a variable is interoperable, but a restriction a little later in this section says that BIND shall not be specified for a variable or common block that is not interoperable. This restriction would seem to make the BIND attribute irrelevant if it can't be specified for anything that doesn't already have it. I think the term "is interoperable" is being used for two different things here. (Paper 00-211 changed the term, but the same problem of dual use existed before that change). Also note that one case includes common blocks, but the other doesn't. paper 00-215, BIND(C) syntax issue 275 - ENTRY syntax The bnf for does not say what I suspect was intended. Note that the bnf correctly requires parens after if RESULT is specified. That makes sense in that RESULT is only for functions, where we do require the parens even when there are no arguments. But by adding the BIND stuff where it is in the bnf, we require the empty parens, even for subroutines, when BIND(C) is specified. I doubt this was the intent. It's certainly non-intuitive and just an artifact of the way the bnf is done. If this bnf stands, then the example in Note 12.41 (example of binding labels) is invalid. paper 00-225r1, /data issue 276 - identifier The issue specified in the paper is numbered 276. paper 00-184r2 - command line issue 277 - command line argument distinction We say here that the use is determined by type and rank. But then the folowwing subsections list things other than type and rank as determinating criteria. They, for example, specify things like lower bounds. I'd guess that perhaps the other requirements are just requirements that the arguments in question have to meet. But they aren't phrased that way. They are phrased as part of the conditions that determine which kind of argument you have. issue 278 - command line argument shape/size What happened to the former requirement that the argument text program argument be assumed shape> Paper 00-184r2 described itself as being wording changes rather tyan specification changes, but it deleted that requirement. Was that an accident or intendional? Likewise, it deleted the requirement that the argument length program argument be assumed size. And this draws my attention to the difference. Why were they not the same in this regard? issue 279 - arguments about arguments to arguments I find the above phrase "arguments to the argument text program argument" to be confusing. That's because "arguments" does normally take "to" so the phrase looks like that's what it is doing. The "to" actually goes with the "assign" from 11 words before it. Or maybe it's just that I'm impressed by getting that many occurrences of the word "argument" in such quick sucession. paper 00-195r2 issue 280 - example for allocate with source= The issue specified in the paper is numbered 280. paper 00-187r1, external and intrinsic issue 281 - intrinsics as actual args The above sentence about allowing use as an actual argument misses the sense of the sentence in section 12 that it replaced. This just says that the attribute allows the use of these procedures as actual arguments. But it fails to explicitly say that such use is disallowed when the names are not given the INTRINSIC attribute. That restriction does not necessarily follow (there might be other conditions that also allowed it). (As noted on the floor, I did not have time to adequately review the edits of this paper). not from any particular paper issue 282 - non-fortran procedures The first and third sentences of the first para of 12.5.3 are had to parse. It's also hard to figure out what they are trying to say. The third sentence in particular completely baffles me; I cannot figure out what it means. Actually, all of 12.5.3 is a mess and a candidate for rewriting. The unresolved issues in this section are longer than the section itself.