J3/02-211 Date: 31 May 2002 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-011r2 and in the J3 notes of 02-007R2. These changes add 4 new issues, resolve 11, and change 0. This makes a total of 370 issues, 366 of which have been resolved, and 4 of which remain. I. Resolved issues Paper 02-169r1 resolved issue 359. Paper 02-170r2 resolved issue 360. Paper 02-171r1 resolved issue 364. Paper 02-178r2 resolved issue 362. Paper 02-179 resolved issue 363. Paper 02-188r2 resolved issue 357 and 358. Paper 02-194 resolved issue 361. Paper 02-196 resolved issue 366. Paper 02-197 resolved issue 365. Paper 02-198r1 resolved issue 347. II. Changed unresolved issues None. III. New unresolved issues I was going to refrain from adding new issues this time around, but these things need to get fixed. paper 02-188r2 issue 367 - BIND statement Paper 02-188 proposes edits in 5.2.4 to make it clear that the BIND statement applies only to variables and COMMON. Paper 02-188r2 claims this is wrong because the BIND statement is allowed for derived types and procedures. I strongly feel that the 02-188r2 is wrong in saying that John's comments were wrong. Indeed, the disagreement here just makes me particularly certain that clarification (such as John's words) is needed here. I see no evidence to support the claim that the BIND statement is allowed for derived types or procedures. The text sentence in the section specifically cites 5.1.2.4, which specifically restricts itself to variables and common blocks. Further, the constraints in 4.5.1 refer to specific syntax of specifying BIND(C) in a . These constraints are not correct if BIND(C) for a derived type can be specified in other ways. Similar comments apply to procedures. If you want the BIND statement to work for derived types and procedures, then quite a lot of work needs to be done - I don't think you want to do that. We are having quite enough difficulty in getting the C interop material to say what it means already, without adding this new wrinkle of questionable benefit. Regardless of who is right, if J3 experts in interop (the authors of both papers clearly qualify) can't agree on what the current words allow, then those words are not ready for a CD. issue 368 - ENTRY and BIND again The above sentence from 02-188r2 doesn't make any sense. It seems to assume a one-to-one correlation that does not exist between subprograms and function/subroutine/entry statements. A subprogram has a single function or subroutine statement, but once you add entry statements, there is no unique statement for the subprogram. There is a statement for each procedure defined by the subprogram. The explanation in 02-188r2 explicitly says that each entry may have a different BIND attribute, but the above words certainly don't say that and, insomuch as one can figure out what they say, I'd tend to read them as implying the opposite - that if any function, subroutine, or entry statement in a subprogram has BIND(C), all of the procedures defined by that subprogram are interoperable. The standard has to be able to stand on what it actually says rather than on asking the writers what they meant. paper 02-204r1 issue 369 - Interp JP-04 I do not believe the above to be a correct translation of the corrigendum 2 edit for JP-04, but I entered it as specified. The corrigendum used the bnf "". I believe that the appropriate translation into f2k would be " or ". The paper instead translated "" into the non-bnf "target". There are critical differences. A pointer is never a target but may be a . That is, a pointer may appear on the RHS of a pointer assignment, but in that case, the target is not the pointer, but is the target of the pointer (if any). The wording of this paper implies that you cannot use a pointer in this context in a structure constructor; that would be an f95 incompatability (and a silly one). issue 370 - Interp JP-08 I also do not believe the above para to be a correct translation of the corrigendum 2 edit for JP-08. The corrigendum used a bnf term that was specific to character type. This paper substitutes a more general term that is also used in other contexts. It needs to restrict it to s used in CHARACTER specifiers. The xref to 5.1.1.5 doesn't do this, as it is just a parenthetical xref (and a bit confusing one after this edit, because that's not where is defined, but just one place where it is used). As is, the edit applies to type-param-values for derived types, where the discussion of length in the rest of the sentence doesn't make any sense. Now that I look at it, I think further work is also needed because it does need to apply to type-param values for derived types, so it needs to be stated more generally in that sense. But it needs to be more restrictive in other ways. In f2k character specifiers can appear in constructors and allocate statements, which doen't necessarily have anything to do with entry to procedures. This restriction needs to be specific to s. (See Note 5.2).