J3/00-163 Date: 3 May 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-011R1 and in the J3 notes of 00-007R1. These changes add 32 new issues and resolve 25. This makes a total of 269 issues, 191 of which have been resolved, and 78 of which remain. I. Resolved issues paper 00-109r1 resolved 64. paper 00-111r2 resolved 79. paper 00-113 resolved 14. paper 00-114r1 resolved 141. paper 00-115 resolved 222 and 224. paper 00-116 resolved 233, 234, and 235. paper 00-120r1 resolved 229. paper 00-122r2 resolved 120 and 149. paper 00-127 resolved 89, 148, 162, 230, and 231. paper 00-128r1 resolved 132. paper 00-134 resolved 215. paper 00-137r2 resolved 3 and 123. paper 00-141 resolved 13. paper 00-147 resolved 82. paper 00-149r1 resolved 227. paper 00-154 resolved 223. II. New unresolved issues paper 00-150, C unresolved issues Issues 238-256 added as specified in the paper. Plus the specified addition to issue 151. The editor also added the following para to issue 249 The editor also wonders why the requirement is there and whether it might be overly broad. One certainly wouldn't want system intrinsics to unexpectedly change the rounding mode on you, but it seems odd that the user is effectively forbidden from encapsulating the rounding mode change in a subroutine. He/she is required to set it in exactly the same procedure that needs it. Seems to me that a user is going to be confused if he/she tries to set the rounding mode in a subroutine and then this work gets undone automatically when the subroutine returns. Seems to me that setting the rounding mode is an awful lot like changing a global variable and should be subject to the same kind of restrictions - no more and no less. I suppose its too late to revisit that question because that's what the TR says. And the editor added the following issue Issue 257 - interoperation with functions I don't know of a single person who has actually read and understood the discussion of interoperation with C functions without having to have it explained to them. I know several people who have tried and gotten it wrong. I take this as a sign that it needs serious work. I believe one of the biggest issues is that people think that the requirements for interoperation relate to actual and dummy arguments. Instead the requirements relate to Fortran dummy arguments and C formal parameters. The "usual" rules apply for how actual and dummy arguments must match. Yes I know that its technically described correctly, but it is not clear. What I think we need is a complete example, not just of a Fortran interface and a C prototype, but of a Fortran procedure calling a C procedure. The example needs to explain how the rules for actual and dummy argument matching fit with the rules for C function interoperation. Might even be that a few more normative words are needed about this. Note 16.3 in 16.2.1 is perhaps a good start, but it needs more explanatory words. And it also needs at least a reference in 16.2.6. In fact, it might be better placed in 16.2.6 with a reference from 16.2.1. This has to do with more than just character data. paper 00-112r3, command line Issue 258 - argument length program argument I find it a challenge to parse the 3rd para of 11.1.1.3. I also find it a challenge to fix it, so I didn't. And is the 4th para intentionally phrased in the most confusing possible way? After careful reading, I think that its really a requirement that the length of the program text argument be ge the significant length of any of the command arguments (or the command name). That's fairly simple. But it is turned around to be expressed in terms of constraining the argument length argument values. This isn't really a limit on the argument length values. Nothing allows those values to be anything different from their "correct" values. This just means that the argument text argument needs to be big enough. Basically what the note says. I think the material in the note is closer to what the normative text should be, except that we wouldn't use words like "expect" to state a normative requirement. And since its a requirement on the argument text argument, it belongs in that subsection. paper 00-128r1, constant exprs issue 259 - nonconstant in namelist Two cases on "nonconstant" remain in the constraint on namelist in 5.4. After waffling about picky things like omitted character lengths, I decided to get on with other edits and let someone else do the exact wording here. There is another case in 12.3.1.1 (Explicit Interface), item (2)(g). And another in the glossary entry for automatic data object. issue 260 - examples of constant exprs Note 7.16 in 7.1.7 refers to constant expressions twice. I could fix the first one trivially, but what to do with the second is less obvious. paper 00-140r1, async/volatile issue 261 - assumed shape or pointer array Is it not redundant to say "an assumed-shape array or a pointer array?" I thought that all pointer arrays were required to be assumed-shape arrays. I find the redundancy confusing here. paper 00-143r2, misc issue 262 - intrinsic The standard should avoid blatantly contradicting itself on the definition of intrinsic. The definition in 2.5.7, which is also in Annex A, is directly contradicted by the statement in 1.5 that a processor may define additional intrinsics. The definition in 12.1.2.2 seems more in accord with the usage in 1.5. Section 13.0, in contrast, appears to lean more towards 2.5.7. There may be other references elsewhere. issue 263 - interface block The editor finds the first sentence of 2.2.3.4 quite hard to read, but will leave any fixups to others. "For" and "through" don't seem like very parallel concepts to be joined by an "or", which is probably part of the problem. Probably breaking into multiple sentences might help. paper 00-149r1, enums issue 264 - C type compatibility I'm not confident of my C standard-speak, so I didn't just fix the first sentence of the above note in 4.7, but it looks wrong to me. Is type-compatibility something defined by the C standard or by a C processor? I would have thought that it was defined by the standard. In that case, you wouldn't say that the C standard requires that a processor make types compatible under certain conditions. You would just say that the C standard specifies that the types *ARE* compatable under those conditions. That this compatibility implies the use of the same representation is a separate matter. issue 265 - enums The issue specified in the paper is numbered 265. paper 00-154 issue 266 - polymorphic entities The definitions of the term "polymorphic" in 5.1.1.8 and in the glossary specifically apply to data objects only. Is there a reason for this? We appear to have polymorphic entities that are not objects. Indeed, the glossary definitions of "declared type" and "dynamic type" both refer to entities, making it seem strange when all three definitions are looked at together. Section 7.1.4 refers to the declared and dynamic types of an expression and certainly appears to acknowledge that there are cases where the two might differ (which sounds to me like a polymorphic entity that is not an object). The concept is then used in 8.1.4. paper 00-151r1 issue 267 - definition of operands The 3rd para of 7.1.8.0 seems largely redundant with the first sentence of the second para...except that it also seems wrong. Section 14.7 defines what it means for an object to be defined. (Strange that the glossary entry for "defined" doesn't refer to anything in 14 at all). According to 14.7, a structure is defined if all of its subobjects are defined. Apparently 7.1.8.0 requires that even components that are not subobjects need to be defined. As I read it, 7.1.8.0 prohibits any defined operations on a derived-type object that has a disassociated pointer component. I doubt that was intended. For that matter, I'm somewhat surprised that we require the whole object to be defined in order to do a defined operation anyway. Why should we care that an object has some undefined components as long as the function that implements the defined operation doesn't reference those components? Apparently its ok to write z=f(x,y) where x and y might have undefined components, but its not ok to write z=x.op.y where .op. is a defined operation implemented by the same function f? Strange. (In the explicit function call, x and y are not operands). A more-or-less separate question that I tripped over while writing this up. Section 7.1.8.0 applies only to operands. I don't know why we have to spell all this out for operands, including the redundant bits about pointers and allocatables, but we don't have to say the same things about the expr in assignment statements for cases where the expr does not involve any operands, such as x=y, x=(y), or x=f(y). I ran into this odd distinction when I was about to mention intrinsic assignment of derived types with pointer components (which we do define for cases where the pointer components are not associated), but then realized intrinsic assignment wasn't an operation, so 7.1.8.0 wasn't even pertinent. paper 00-144r1 issue 268 - component-array-spec constraints The placement of the above two constraints on component-array-spec doesn't make it clear that the constraints also apply to component-array-specs in a component-decl, since the bnf for component-decl follows these constraints. The constraints refer to other component-attr-specs, so it is not at all obvious that they would necessarily apply outside of a component-attr-spec-list. They were "clearly" intended to apply. I thought the wording in the now-deleted (by 00-144r1) constraint on allocatable was better in that it referred to the dimension attribute rather than to the syntax of specifying it. issue 269 - constraints on passed-object dummy args. I put the above constraint (on kind parameters of a passed-object dummy argument) here as specified, but I found it confusing why it was separated from the other constraints on passed-object dummy args. Which does it apply to? Likely both. Probably the more basic problem is that the definition and some constraints for passed-object dummy args are done twice, in almost identical words, for two different places in the same statement even. One is two constraints above this one, and one is the next constraint after. I don't know what determined what constraints got said twice and what ones got said once and apply to both places.