J3/99-176 Date: 16 June 1999 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 99-011R2 and in the J3 notes of 99-007R2. These changes add 10 new issues and resolve 24. This makes a total of 211 issues, 87 of which have been resolved, and 124 of which remain. Of the new issues, 5 are additions by the editor, and the other 4 are new issues specified in papers as passed. Two other new issues specifies in passed papers were resolved by other papers at the same meeting, and were thus not added to this list. I. Resolved issues paper 99-132r2, issue 15 resolved 15 Paper 99-140r2, issue 191 resolved 191 Paper 99-146r3, issue 9 resolved 9 Paper 99-147r2, issue 143 resolved 143 Paper 99-148r2, issue 16 resolved 16 Paper 99-149r1, issue 35 resolved 35 Paper 99-150r1, issues 77 and 131-133 resolved 77, 131, 133 Paper 99-151r1, issue 139 resolved 139 paper 99-156r1, misc edits resolved 115, 146, 157, 159, 164, 169, 172 paper 99-160r1, fixups to 16.2.6 resolved 106, 107, 109 paper 99-162, issue 76 resolved 76 paper 99-163r1, issue 130 resolved 130 paper 99-164r1, issue 44 resolved 44 paper 99-166, issue 10 resolved 10 II. Changed unresolved issues Paper 99-150r1, issues 77 and 131-133 Issue 132 - Expression classification confusions Part, but not all of this issue resolved, as per the approved edits. Paper 99-156r1, misc edits Issue 144 - linking to non-C procedures The paper fixed the misused commas, so I deleted that part of the J3 note. The substance of the note remains (and the paper did not say to delete it). Paper 99-167r2, more IEEE Issue 22 - IEEE_SUPPORT intrinsics I added the following extra para to this issue: Words modeled after the form of those in the second para of 13.16 ("A program is prohibitted from invoking...") might be workable. III. New unresolved issues Paper 99-148r2, issue 16 Issue 202 - previous abstract interface block I'm not sure whether the phrase "previous abstract interface block" is quite what is wanted to describe where the characteristics of a procedure pointer that appears in a generic interface block are defined. The abstract interface block does specify the characteristics, but I'd perhaps have said that it was the procedure declaration statement that specifies the pointer to have the interface. In either case, is the usage of the word "previous" intentional here? As I read it, this requires that the abstract interface block that defines the abstract interface for the pointer is required to be previous to the generic interface block where the pointer is listed. This seems like a strange requirement, particularly since (unless I missed it), the procedure declaration statement for the pointer is not required to be previous to the generic interface block. The compiler won't know that the abstract interface is even relevant until it sees the procedure declaration statement. Note also that the compiler is already required to deal with forward references in the context of a generic interface block because some of the procedures listed might well be module procedures in the CONTAINS part of the module. Paper 99-156r1, misc edits Issue 203 - procedure components in BIND(C) types The paper's J3 note on this in 4.5.1 is numbered 203. Issue 204 - prototype with external linkage Although paper 99-156r1 fixed the use of "C function" that was the subject of issue 159, it leaves the above condition (item 1 in 12.5.3) in a pretty confused state. Its hard to figure out what modifies what. I don't think (though I suppose I could be wrong) that a C prototype can be said to have external linkage. Perhaps this phrase is suppose to modify "procedure". And I also doubt that a linkage can be said to have a binding label. Paper 99-167r2, more IEEE Issue 205 - IEEE functions in constant expressions Admitedly we don't use constant expressions much. Perhaps we might be able to eradicate them completely and eliminate confusions like this, but as long as they are still defined, we need to keep the definition sensible. As of 99-007r1, the definition of initialization expression no longer depends on the definition of constant expression, but my impression was that it was still intended that initialization expressions be a subset of constant expressions. Otherwise it is quite confusing that we can have a named constant that is defined by something that isn't a constant expression. Specifically, since IEEE_SELECTED_REAL_KIND may be used in an initialization expression, but not in a constant expression, it appears to me that the expression IEEE_SELECTED_REAL_KIND(5) is not a constant expression, but that if we have INTEGER, PARAMETER :: R5 = IEEE_SELECTED_REAL_KIND(5) then R5 is a constant expression. Since I'd have to search to find where we still use constant expressions, I'm not sure what actual difference this makes to anything, but its sure confusing. Perhaps the best answer to this is to finish the eradication of constant expressions. Either that or remember that anything added to initialization expressions also needs to be added to constant expressions. Issue 206 - More IEEE functions in initialization expressions Why just IEEE_SELECTED_REAL_KIND and not anything else from the IEEE modules in initialization expressions? We allow all sorts of intrinsic functions, including some of questionable utility. Some of the IEEE functions also seem questionable, but there are some that seem more useful than most of the intrinsic functions that we do allow. The main one that comes to mind is IEEE_VALUE; if you are really using NaNs and infinities, it would likely be useful to use them in initialization. Indeed, initializing things to NaN can be *VERY* useful in diagnosing some problems. I predict people will try and will wonder why it fails. Issue 207 - IEEE specification functions If I read correctly, all of the functions in the IEEE modules are specification functions. This might be worth mentioning in a note (either a para added to the above note 7.13 or a separate note of its own). Paper 99-168r1, foreword Issue 208 - data stuff in foreword The paper's J3 note on this in the foreword is numbered 208. Issue 209 - I/O stuff in foreword The paper's J3 note on this in the foreword is numbered 209 Issue 210 - Intrinsic procedure stuff in foreword The paper's J3 note on this in the foreword is numbered 210 not from a paper this meeting Issue 211 - flattened form The term "flattened form" is used in 4.5.6.1, but it is nowhere defined. The closest thing to a definition is an example in note 4.46, but an example does not constitute a definition, even if the note were normative.