J3/01-349 Date: 1 Oct 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 01-011r3 and in the J3 notes of 01-007r3. These changes add 6 new issues, resolve 4, and change 0. This makes a total of 345 issues, 335 of which have been resolved, and 10 of which remain. I. Resolved issues paper 01-270r2 resolved 339 paper 01-273r2 resolved 333 paper 01-326 resolved 338 paper 01-332r1 resolved 337 II. Changed unresolved issues none III. New unresolved issues paper 01-323 issue 340 - F90 compatibility The issue in the paper is numbered 340. paper 01-319 issue 341 - BIND description placement As was mentioned on the floor when paper 01-319 was debated, it introduces an organizational problem (or perhaps just contributes to exacerbating one that was already there). The paper was passed with the understanding that the organizational problem would be fixed "later". I thought that integration was exactly the kind of time when we should be giving special attention to things like this, there not being much in the way of "later", but anyway... This issue is to at least document the problem so it doesn't get forgotten. The description of BIND in 5.1.2.4 seems a bit misleading in that it talks about the BIND attribute for procedures, but is in a section (5.1) about type declaration statements. This incorrectly implies that type declaration statements have something to do with specifying the BIND attribute for procedures. Admitedly there are similar confusions for other attributes, but I'd rather see us solve problems than add to them. This case doesn't seem difficult to solve. The BIND attribute is fundamentally part of C interop. I think it's description can thus best be treated in the section on C interop (16). I'd move most of 5.1.2.4 into section 16, leaving 5.1.2.4 to be just a one-liner that xrefs the description of BIND in section 16. Alternately, we could do more surgery on section 5 and fix the other similar problems too. paper 01-325r2 issue 342 - Organization of BIND requirements Paper 325r2 fixed a technical problem with the requirements on the BIND attribute for procedures. However, in the process, it created an organizational problem. The requirements used to be specified (albeit incorrectly) in this section (15.2.6). They are now spread all over the place. This is an important enough set of requirements that it merits collecting in one place, just like we have one place where the requirements for explicit interfaces are collected (12.3.1.1). Whether that one place is best in c12 or c15 is arguable, but I feel strongly that there should be one place. Floor discussion suggested that the paper be passed, with an unresolved issue (here it is) added about the organizational problem. As with issue 341, I am disappointed that we appear to be procrastinating the solution to organizational problems, and indeed adding more such problems when we are supposedly in integration, which should be the time to address them. It makes me think that we aren't yet serious about doing integration, but instead are just narrowing our focus to doing point fixes. If we still have so many point fixes to do that we can't broaden our perspective, then maybe we aren't yet ready for integration. Integration involves more than moving one's narrow focus to a different section. paper 01-265r1 issue 343 - Moment a connection is established The above para and note in 9.4.5, added by paper 01-265r1, adds more confusion than it solves in my mind. I found the concepts of new and existing files pretty clear before. The only possible confusion was with replace, which I thought was clarified pretty explicitly in the subclause on status (where it says that replace causes a new file to be created). The new text tries to define these terms based on a concept of "the moment the connection is established". I cannot find that concept defined anywhere and its definition is far from obvious to me. If the OPEN creates a file, I could well imagine that one might consider the OPEN to first create the file and then establish the connection to it. Perhaps we have stuff defined in such a way that this can't be but if so it is subtle and non-obvious. It seems to me that we are trying to define a simple concept in terms of a complicated (and undefined) one. The only "definition" of this concept appears to be in the new note, which is so full of qualifiers that it doesn't establish any case where this situation does, in fact, happen. And its "for example" phrasing imples that there are other possibilities in addition to the status=replace one. Are there? So the note neither tells me where this does actually happen or where it doesn't - not much of a definition. This frankly sounds more like it is talking about race conditions where some other process deleted the file while the OPEN statement was executing. If so, that is far out of scope to even be discussing - might as well talk about how shared memory and race conditions could case the assignment x=x to change the value of x. Since J3 passed this paper (over my objection about insufficient review), I don't feel it within editorial prerogative to just not do this part. But I will use this note to point out how bad I think it is (pretty bad). paper 01-266r2 issue 344 - I/O rounding again No, I'm not just re-raising my old issues relating to rounding mode here (even if I do still disagree with what we have), but the committee appears to have introduced a new inconsistency here by passing paper 01-266r2. I had once griped that it was anomalous that compatable mode was specified so much more precisely than the other modes for non-IEEE systems. J3 dismissed that concern. Paper 01-266r2 reraised that aspect and attempted to fix it. But in doing so, it omitted one case, thus leaving a different inconsistency than before. We now precisely specify up, down, and nearest, in addition to compatable. Indeed, we precisely specify everything other than RZ. Why the omission? I'm also wonder (but am not sure) whether the new specifications on up and down might be identical to the IEEE ones. If so, it seems strange to make the distinction between IEEE-conformant and non-IEEE conformant systems, where we requite non-IEEE machines to do the same thing as IEEE ones. I have no problem with just plain requiring IEEE conformance for these modes if that's what we want. But if we do so, we should do so straightforwardly instead of pretending that there are two different classes, which happen to have identical requirements. I don't actually know that this exactly matches the IEEE requirements, but darned if I can think what would be different. paper 01-268r1 issue 345 - bind attribute for entry Paper 01-268r1 added the above qualification in 12.5.2.7 about applying only to entry statements without a proc-language-binding-spec. That qualification appears to be inadequate because a proc-language-binding-spec need not have a NAME= specifier. I almost changed it to talk about NAME= specifier, but then realized that fix might miss perhaps the only thing that really needs to be said about entry here - something that is obscured by all the unnecesary stuff. As best as I can see, the only thing we need to say here about entry is that an entry without a proc-language-binding spec implicitly has the BIND attribute without a NAME= specifier if it appears in such a subprogram. Once we've said that, we don't need to repeat the bit about binding labels and lower-casing - the previous sentences in the same para apply as is (because the entry name is the name of the procedure). This isn't the right place to say what needs to be said, because we don't need to say anything special about binding labels (which is what this section is about). The material that we do need to cover should be in 12.5.2.4 (Entry statement), along with all the other things about attributes that the entry automatically gets from the function or subroutine statement. No relative of the word bind appears in 12.5.2.4 except in the bnf. It needs to.