J3/99-103 Date: 13 Jan 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-011 and in the J3 notes of 99-007. There are now 121 issues in the 99-011 document, 23 of which have been resolved. I. RESOLVED The following issues have been resolved. The J3 notes have been deleted and the 99-011 indicates these are resolved. The following issues are resolved by paper 98-226R1. 53-58, 60 The following issues are resolved by paper 98-227R1. 36-43, 45-52 II. CHANGED UNRESOLVED ISSUES The following unresolved issues have been at least partly addressed, but some aspect remains unresolved. The J3 notes have been edited to reflect this. Paper 98-226r2 issue 59 Progress made, but it isn't done. Plus it reminds me of a larger issue. J3 note 59 moved to 7.1.4, and reworded as follows. I'm not at all sure that the definition of the dynamic and declared types of an expression in 7.1.4 is adequate. It needs review. Note as a larger issue that we really need a single term to describe the type and type parameters. For example, when we talk about declared and dynamic types, we probably mean to include the type parameters. Otherwise, we'll also have to say something about declared and dynamic type parameters. This whole area needs more work than I can do right now. Paper 98-227r2 Issue 35 Mostly fixed, but one question remains. I notice the syntax allows a "contains" followed by nothing. This is unlike the contains that introduces an internal procedure part. Is this intentional? Nothing necessarily wrong, but it seems discrepant. As an alternate thought, perhaps we should leave this alone and change internal procedures and modules to allow them to be empty also. Issue 44 I can't find that the last sentence in the issue was addressed. Namely: Are there any requirements relating to accessibility changes when overriding a binding? III. NEW UNRESOLVED ISSUES The following issues are all new. Each has a correspondingly numbered J3 note in 99-007, which contains the same text as the descriptions below. Paper 98-228R1, pub/priv components. Issue 61 - component accessibility in extended types Paper 98-228R1 said to copy the example below from 98-198, with some changes, which I have done. However the changes deleted the public and private specifications in the extends statements. Without those specifications, the subsequent comments that were intended to illustrate the differences make no sense. Which makes me notice that the edits in paper 98-228R1 do not implement that part of the syntax passed in 98-198. I vaguely recall some email discussion on this subject, so the change may have been intentional. However, if so I would have expected paper 98-228R1 to say that it incorporated a syntax change. It doesn't say anything about this, leading me to the conclusion that it is just an incomplete set of edits. If there is a spec or syntax change, I expect to be told so explicitly rather than having to deduce this by studying the edits. If the syntax of paper 98-198 is still our intent, then the edits to implement it need to be finished. Also a little better introduction to the example code in C.1.3 is needed. (I could do that part myself, but its a waste of my time if that's not what is intended). If we are changing the syntax of 98-198, then we need to pass a paper that says so. We also then need to considerably rewrite the example code in C.1.3. Will also need to rewrite the para in 4.5.3.1 (inheritance) that talks about the accessibility of the subobject denoted by the parent type; it doesn't make any sense as it stands now since there is no single accessibility of all of the additional components. I suspect this is what is intended, but I'm not going to do it myself. Issue 62 The first para of 14.1.2.5 obviously is nonsense in the presense of mixed public/private components. I'd also have thought that this was not a particularly subtle place to look for things that would need changing when component accessibility is changed. I could rewrite it, but I'm tired of all the work I've already had to do for this paper. The authors of edits papers are going to have to start taking a little more responsability for doing some of their own checking. I can't continue to do the job of editor if I'm expected to do all of this for them. Paper 98-242R1, misc edits. Issue 63 - Unit numbers for * Added per item 13 of 98-242R1. Issue 64 - ROUND= for unit * Added per item 19 of 98-242R1. Issue 65 - Semicolon separators Added per item 12 of 98-242R1. Paper 98-229R1, initial/final Issue 66 - Initial/final Added per vote on paper 98-229. Incomplete section 6.3 with reference to initial draft in 98-229R1. Paper 98-211r2, stream i/o Issue 67 - Spelling of I/O Added per passed edits. Issue 68 - Unlimitted length formatted records Added per passed edits. Issue 69 - Effective items in I/O lists Added per passed edits. Issue 70 - DTIO wording assumes formatted Added per passed edits. Paper 98-208r2, explicitly typed allocs Issue 71 - restricted-type-spec Added per passed edits. I also added a sentence questioning whether restricted-type-spec was the best term here (since it isn't a subset of type-spec). Issue 72 - allocatable variable The instructions in 98-208r2 after the deletion at [60:7] said to "Replace 'allocatable array' by 'allocatable variable' everywhere it appears." This is not an acceptable instruction. I have done nothing about it. Perhaps I misinterpret the instruction. But there are no cases of this phrase on line 60:7, and no other indication of the scope of "everywhere", so I assume it means the whole document. A quick grep reveals several cases where this would clearly not make sense without some additional re-wording. The editor does not accept the task of looking at every case and deciding what should be done about it. If a paper specifies something global like this, then I expect the author of the paper to have checked every case and verified that it is appropriate for each one. If the author doesn't have time to do this, then don't expect the editor to. The very first line of my grep results is the Glossary entry for "allocatable array". You propose to turn this into "allocatable variable", which is then defined to be an array? I think not! An interesting case is the allocated intrinsic, where we presumably do want it to accept scalars, but the dummy argument is named ARRAY. (And recall that changing a dummy argument name WOULD cause an incompatability for user code. Probably most users don't use the keyword form here, but it is certainly allowed). While I'm on the subject of neglected tasks here, I don't know how it can be pretended that a change like this (adding allocatable scalars) has been adequately researched unless the author has checked every occurance of the word "allocatable". I count 146 lines on which it appears. Many may be ok as is, and many others may be adequately fixed by the "array" -> "variable" change. But I expect someone to actually check this, and I'm not volunteering. I end up doing enough of that kind of checking already. For obvious candidates, might there not be something worth saying in the sections on the allocatable attribute and the allocatable statement? That shouldn't have taken a grep to deduce. Perhaps this is partly covered by one of the emails I recall having gotten subsequently. But I'm not dealing with them until the passed papers are done. In any case, a listing of a bunch of other places not noticed before does not do anything to give me confidence that a thorough search was done. Grep is your friend. I expect someone to check *EVERY* one of the 146 cases, not just the places where it occurred to someone to look. If someone isn't willing to do such a check, then we shouldn't make this change. Issue 73 - allocatable char components May the char length of a component be deferred? The 2nd constraint after R433 says not. Issue 74 - allocate statement How is it that we can have an allocatable or pointer array with a shape that is not deferred? I didn't see any edits to allow that. If this statement applies to all arrays, then it would be simpler to say that instead of implying that there are some array cases it doesn't apply to. And likewise, 2 paras below, why do we even talk about the possibility that a value might not be specified for every type parameter since there is a constraint on derived-type-spec saying this can't happen? Hints: the appropriate edits elsewhere were forgotten, and I've not got time to draft them on the fly. Issue 75 - type parameter agreement in allocate Is it or is it not a requirement that type parameters in an allocate statement agree with those of the declaration? Paper 98-208r2 says that it is a requirement, but then goes on to say that there is an error condition if this requirement is not met. If a requirement is not met, then the program is non-conforming, so I've omitted the "otherwise" bit. If this is not a requirement, then don't state it as one. I could probably fix this up, but I'm not inclined to. I've spent far too much time on this paper already. Same thing again a few paras later about the requirement that allocate-shape-spec-list agree with the declaration of non-deferred-shap arrays. Van, you need to watch for this (same thing shows in at least one other paper also). You need to make a distinction between things that are violations of the standard and things that generate error conditions. It is not a violation of the standard for code to generate an error condition. So do *NOT* use phraseology that confuses the issue. If you say that something shall be so, then that means it is a violation of the standard for it not to be so. Issue 76 - type parameter syntax in allocate I've entered the above para (on specification of type parameter values in ALLOCATE statements) verbatim from paper 98-208r2 because it has so many problems that I despair of fixing any of them. I'm not actually sure what this para is trying to say at all. I think that perhaps it might be trying to address the issue that 4.5.5 says that a type-spec has to specify all the type parameters for a derived type, wheras we don't want that to be a requirement here. That does need to be handled somewhere, either by changes in 4.5.5 or by something here. But it is far enough from saying what needs to be said on that matter that perhaps that isn't its intent. This para uses the term "associated" extensively, even though that term is not used in 4.5.5. We use the term associated in very specific technical contexts, which this isn't one of. It appears to me that the whole para does nothing but restate the 4th constraint in 4.5.5 in a more convoluted manner. I don't see why it needs to be repeated here at all; it is *NOT* one of the things that is different. I note finally that this para seems to forget that the syntax allows intrinsic types in the type-spec; 4.5.5 is about derived types only. Issue 77 - restricted exprs Paper 98-208r2 added the above requirement about type parameters in restricted expressions. Isn't a simillar thing needed for constant and initialization expressions? Hmm... And 4.5.1.1 says that type parameters may appear as primaries in specification expressions and initialization expressions, but I don't see anything in 7.1.6.1 and 7.1.6.2 on this. That problem presumably came from my own paper on pdts; its not new in 98-208r2. Issue 78 - assumed type parameters in pointer assignment The above para on assuming type parameters in pointer assignment doesn't seem to jibe with the constraint that requires all of the type parameters to agree (with no exception for deferred type parameters). I also suspect that it probably needs to talk about dynamic type parameters (say, in case target had deferred type parameters), but I'll let someone else figure that out. Issue 79 - dummy arg type parameters The above description of dummy argument type parameters could be interpreted to mean that, having assumed the type parameters from the actual argument, the dummy argument shall not then be reallocated with different type parameter values. I don't think that was the intent. And if it was, that better be made explicit lest this be misinterpreted the other way. Also, I find this condition a bit strange. Is this really what is wanted? Looks to me like I can pass an actual argument with deferred type parameters to a dummy that has no deferred type parameters. Presumably I allocated or otherwise did something to assign specific type parameter values to the actual first...hmm...perhaps more needs to be said there also. But once I add a single deferred type parameter to the dummy, then the actual can't have extra deferred parameters, even if they were already assigned specific values? I don't know what is really best here, but I fond it confusing. Has this really been thought out? Issue 80 - char-len-param-value Should we eliminate the bnf term char-len-param-value? It is now identical to the more generally named type-param-value. Looks to me like we could just replace all instances of char-len-param-value (except for its definition, of course) by type-param-value. This would ameliorate problems like forgetting to mention char-len-param-value as a special case. The term is used only in 5.1.1.5 and one time in 5.1. I'm inclined to make the change, but would like concurrance before I do so. Issue 81 - deferred type param inquiry I'm certain that this (section 4.2 or 4,3) is the wrong place to talk about restrictions on type parameter inquiries. More appropriate would be 6.1.3, where type parameter inquiries are defined, and somewhere in section 13 for the special case of the LEN intrinsic (probably 13.5.4 and/or 13.15.55). Could also be relevant to 7.1.6.x, but looks like we are covered ok there. Issue 84 - deferred parameters in implicit Do we allow deferred or assumed type parameters with implicit? I'm not sure either whether we want to or whether this is already covered. Paper 98-243r1, explicitly typed array constructors Issue 82 - zero-sized array constructors The following requirement is proposed to solve the ambiguity questioned in one of the f95 interps. This might be interpreted as invalidating some existing f90/f95 programs, but the validity of such programs under f90/f95 is not clear. Different f90/f95 compilers exhibit different behavior in this area. The requirement is not a constraint because it is not always checkable at compile time; this allows those processors that currently allow the code in question to continue doing so as an extension. If this requirement is added, then it also makes sense to make the ac-value-list optional, allowing a natural syntax for a zero-sized constructor (which does have uses). The type-spec shall appear if the array-constructor is of size zero. Paper 98-240r1, C interop Issue 83 - C standard ref Presumably section 1.8 will need a normative ref to the C standard to go with C interop. And then we ought to cite the ref somewhere in the text. Issue 85 - target C processor I can't find any definition of the term "target C processor" used in 4.5. This seems like too important a concept to leave undefined. Presumably 4.5 is not the best place to define it. It probably belongs early in the new section 16 - likely in what is now labelled as an introduction to be added. But I'm putting this note in 4.5 to make sure that the terminology used in 4.5 is consistent with whatever gets defined in 16. An xref might even be appropriate. Issue 86 - BIND(C) and SEQUENCE Perhaps it has already been adequately debated. Or perhaps it is implicit in the decision to use BIND(C) instead of SEQUENCE(C). If so, ok. Otherwise... I wonder why the prohibition against having both SEQUENCE and BIND(C). It seems to me that there is nothing inconsistent about this combination. If there are two different f2k types that interoperate with the same C type, I'd expect them to be able to interoperate with each other. Thus I'd find it natural to be allowed to specify SEQUENCE to allow such interoperation. I don't see that we'd have to say anything extra to make this all ok. Obviously a type that was both BIND(C) and SEQUENCE would have to meet all the requirements for both. Issue 87 - Constraint for VALUE Should not the first sentence of 5.1.2.14 be a constraint, either here or in 5.1.0? It looks compile-time checkable and I'd think you'd want it to be. See the comparable stuff for INTENT(IN), which is a constraint in 5.1.0. Oh, I see. Part of this is duplicated in a constraint. But not the part about being in a BIND(C) procedure. Hmm. And while I'm looking at the applicable constraints, shouldn't we also constrain the VALUE attribute against being applied to dummy procedures like the constraint for INTENT? I suppose it is implicit in that BIND(C) implies INTENT(IN), but I'd think it better to be more explicit. Issue 88 - redundant constraints Not the biggest issue in the world, but... Isn't the constraint about value-stmt appearing only in the specification part of a subprogram or an interface body redundant? By the syntax rule, it is required to specify a list of dummy-arg names. That pretty much restricts it to places where there are dummy arguments. I sure can't figure out how the constraint is going to be violated without also having violated the syntax rule. I'd argue for simplification here. Yes, the same comment applies to the comparable constraints on the INTENT and OPTIONAL statements, but just because we wrote it that way before doesn't mean we needed to. I'd say to kill all 3 of these constraints. Issue 89 - value attr and character length Is it just me or do the first two parts of the constraint on character lengths for VALUE arguments seem a bit strange? I was sure surprised after reading that the length parameter could not be these fairly complicated things to discover that, in fact, it has to be exactly one. That was a bit of a letdown after the leadin of the first two parts. Perhaps you are trying to avoid questions like whether it could be assumed or a non-constant expression as long as it happens to be 1 at run time. If so, how about a simpler wording like "the character length parameter shall either be omitted or be a constant specification expression with the value 1". I assume, by the way, that you do want to allow the length to be omitted (and thus implicitly 1). I'm not entirely sure whether the proposed wording allows that or not. I propose making it explicit to avoid the question. Issue 90 - VALUE and ASYNCHRONOUS Added per passed edits. Issue 91 - Intro for c16 Added per passed edits. Issue 92 - C terminology Added per passed edits. Issue 93 - Meaning of interoperability Perhaps it is intended to cover the issue in the introduction to c16 mentioned in unresolved issue 91. But just to make sure... The current words pay a lot of attention to the technical requirements for C and Fortran things to be interoperable, but I can't find anything that talks about what it means to be interoperable. Do they just sit there in pride of having this label, or does it have some consequence? And in a few places, I find the usage to be confusing. For example, we define what it means for a Fortran procedure to interoperate with a C function, but I find that concept confusing. It sounds like you have both a Fortran procedure and a C function that somehow work together. Instead, you presumably actually have only one of these and you want to say that it could be invoked as though it were the other....or something. Anyway, I can't find words saying what presumably needs to be said about things like this, and those words that I do find confuse me. Issue 94 - C global vars and name mangling I can't find anything about C global variables or name mangling. Presumably to come. Issue 95 - C_NULLCHAR vs C_NULL_CHAR Should C_NULLCHAR possibly be spelled C_NULL_CHAR? I think everything else in the C interop stuff that is composed of multiple words has the underscores. NULL and CHAR look like separate words to me. Feel free to "just say no", but I thought I'd raise the question. Issue 96 - C_NULLCHAR when there is no C processor I might not have questioned it if we just required C_CHAR to have a valid kind value. It would be an unusual processor where it didn't... Unless perhaps the processor had no C compiler at all....Say, hadn't we better be sure to address that possibility explicitly? We aren't saying that it is impossible to have a standard-conforming Fortran processor on a machine that doesn't have C are we? I hope not. That should be addressed in the definition of the target C processor. This might affect note 16.3 about C pointer types. Anyway back to question I first intended to raise here. (Looks like I've squeezed 2 into a single J3 note). Since we went to all the trouble to specify the kind parameter of C_NULLCHAR in a way that is at least defined when C_CHAR is -1, shouldn't we be equally thorough about its value? How can C_NULLCHAR have a value the same as the null value of the C character type when C_NULLCHAR is not of a type that interoperates with the C character type? Perhaps char(0) or blank? Issue 97 - C_PTR details Don't we need to say a little more about C_PTR somewhere? Like that all of its components are private? And why even bring up the question of type alias name? Since this is defined in an intrinsic module, we don't need to worry about what the code inside of the module looks like - just what its visible aspect is. Hopefully, we aren't implying that the user could notice the difference between a derived type and a type alias name here. And if it is a type alias name, then it might (quite plausibly) be a type alias for something like integer. Thus on some machines, it would be legal to assign an integer value to a variable of type C_PTR, whereas on other machines it would not be legal. This seems like it invites gratuitous incompatabilities. I'd say just require this to be a derived type with private components. If you want to allow a type alias, insist that it be a type alias for a derived type with private components. If the processor wants to internally implement it more like a type alias for integer (for example, if argument passing is different for integers and derived types), that's fine. The user, howver, should not be able to take advantage of this. We want the effect on the user to be just like a derived type with private components - he can't touch its innards directly. Which reminds me of a comment I forgot to make in the type alias section. I would not say that a type alias very effectively "hides" what it is an alias for. If its purpose was "hiding" then it does a poor job, because what is legal to do with a type alias depends directly on what it is an alias for. For example, if it is an alias for a numeric type, then I can assign it a numeric value; otherwise I can't. I think "hiding" is a completely misleading term in this context. Issue 98 - Needs to be determined I left the wording in Note 16.3 about "needs to be determined" as written, but this is not acceptable for the final version. It reads like a requirement. I don't think we want to say, even in a note, that a Fortran program is not standard conforming if the programmer has not determined this fact. Also, think about whether the Fortran standard actually requires a C processor to exist at all before saying that a processor can't have a standard-conforming Fortran if it doesn’t have a C with the right properties. Issue 99 - Corresponding components The requirements for interoperability of structures don't bother to define what they mean by "corresponding" components. May I assume that the correspondence could be by name? Issue 100 - Incomplete type I don't know my C draft well enough to catch all the kinds of things that I normally notice in Fortran stuff. But this wording sounds suspicious. Do you really mean what this says...a struct that contains an array component of incomplete type? Is it the array that is the incomplete type or is it the struct? I'm not sure so I can't fix it. Might even be right. Issue 101 - Struct interop example Note 16.5 looks like it is trying to give an example of structure interoperability, but it seems woefully incomplete. I just typed it is almost as is, making no attempt to complete it. Is there supposed to be any Fortran stuff here? Also, as best as I can tell from the words presented, the secret to making C and Fortran structures compatable is just to use the right type names. If the C one is named myctype and the fortran one is named myftype, then they will interoperate. Its not clear that the sample C code shown has anything much to do with the sentence, though I do notice that it defines a C struct type named myctype. I suppose this might not be a coincidence. Issue 102 - Same types in C Note 16.6 refers to the conditions of the C standard for two types to be the same. My quick glance at the index of the C draft makes me wonder whether this is accurate. The C draft section 6.1.2.6 lists conditions sounding quite simillar to these as being necessary for 2 types to be compatible. That section also uses the term "same type" in a much more strict sense. Do you mean "the same" or do you mean "compatible"? We appear to use the term "same type" for this in Fortran (I had to check, though), but I'm not sure that is the C terminology. Also, if we are going to have a note about this anyway, might it not be appropriate to give a hint as to why the difference instead of just mentioning the difference and letting the user guess why? Issue 103 - Array interop The section on array interoperability leaves me confused about what things it is trying to cover. Is this about global data, C calling Fortran, Fortran calling C, or what? Some of the conditions sound like they are making assumptions about this. I thought Fortran calling C was supposed to be a major emphasis, but some of this doesn't make sense there. In particular, I'm shoked that we are limitted to arrays that are assumed size or explicit shape. So I can't use an allocatable array as an actual arg? Why not. (I’m talking about an allocatable actual arg here - not an allocatable dummy). And I can't use an array constructor or other expression? (Note that explict-shaped arrays are by definition named arrays). I don't think this has been thought through. Shouldn't there be some similarity between what I can pass to an implicit interface procedure (se 12.3.1.1) and what I can pass to a C procedure? I can pass pretty much any kind of array to an implicit interface procedure as long as I don't mind the compiler doing copy-in/copy-out. See I have a sudden vision of code that looks like a wrapper routine written in Fortran, with an assumed size dummy argument, just so that I can call this routine with an arbitrary array expression and end up with it calling the C routine with its assumed shape dummy as the actual to the C. Why force such silliness? And why make me memorize a whole new set of rules for a very simillar issue. Issue 104 - C arrays of arrays Isn't it redundant to require that the element type of the C array not be an array? I'm aware that C has arrays of arrays, but we already require, in the next phrase of the same sentence, that an element of the Fortran array interoperate with an element of the C array. Since an element of a Fortran array is always scalar and we don't have any Fortran scalars that interoperate with C arrays, doesn't that pretty much cover us right there? Issue 105 - Unparseable sentence I am completely stumped in my attempts to parse the last sentence/paragraph of 16.2.3. I think perhaps some lines got left out. Issue 106 - C reference type What is the first sentence of 16.2.4 supposed to be? It looks sort of like it might be intended to be a definition of "reference type", but it isn't phrased as a definition. It also seems like an odd thing to use to introduce a section on functions. Perhaps it is just the author's note to say something about this somewhere. Issue 107 - Result of a procedure Do you mean "result variable?" The "results of the procedure" include everything that it does. But I'm not sure the term "result variable" is right for C. Issue 108 - Corresponding Corresponding means by name, I assume? Issue 109 - C array args How about array args? I thought I recalled something screwy like that a C array formal argument is implicitly a pointer even when you don't declare it like that, and that declaring it a pointer would end up making it a pointer to a pointer. But perhaps 1) I’m just all confused about this, or 2) its screwy but phrased ok anyway because the C think is still a pointer even though the pointerness is implicit. Issue 110 - BIND(C) for procedures Presumably there will be a syntax somewhere that allows one to specify the BIND(C) attribute for a procedure. I can't find it. And whenever it is written, I assume that the restrictions from 16.2.4 will go to the appropriate place. They seem out of place here. It should be a separate issue, but I long ago ran out of toes to count on, so I'll lump it in here. What is the "unless" clause supposed to be about? It is quite surprising. So I can do all of the funny stuff as long as it is in a Fortran procedure called from C? I doubt it. And if I have only an interface body in the calling routine, how am I even going to know whether or not the procedure is defined by a Fortran subprogram? I don't understand this at all. Maybe I need more caffeine...or maybe I've had too much. Issue 111 - Example references inacessible names What is supposed to be the context of the example shown in 16.2.4? If this is supposed to be an interface body, then how did the stuff from ISO_C_TYPES become accessible without a USE statement in sight? I suppose this might be an internal procedure, but in that case it seems to be missing a few things such as an assignment of a value to its result argument. Lets stick to examples that could possibly be legal in some context. Issue 112 - C_PTR example I'd think the last note in 16.2.4 a lot more clear with an example. Its a bit short and cryptic. Indeed so short that it doesn't mention that the types need to agree in the non-value case. For that matter, it doesn't specify that the Fortran C_PTR case has to specify VALUE. It does have to, doesn't it? Issue 113 - Character array args I think the mods to the 3rd para in 12.4.1.2 have suceeded in removing its content. There are some funny and complicated special cases here. You can't get by with just adding "or scalar" because some of the special cases involve scalars. An array element is a scalar last time I checked in Fortran. But we treat array elements specially here.. If the actual arg is a scalar array element, then the dummy *MAY* extend past the end of the actual argument scalar. That was sort of the main point of much of this stuff. The "array element or scalar" doesn't say which one applies when both might, thus leaving each user to choose their own (different) interpretation of this. P.S. If there is one practice I'd like to see deprecated, its the business where a calling routine can't tell whether an array element actual means just the scalar element or the rest of the array. Its funny to describe, as witnessed here, and its got to cause implementation problems in some contexts. But alas, the practice is used too much to get rid of. Issue 114 - non-default char array element substrings Looking at the edits about character args in 12.4.1.2, I'm concerned that there might have been an inadvertant technical change. The former words included stuff about substrings of array elements. Those words have been replaced by words about scalars of type default character. True, we agreed to make the new extension apply only to default character, but I don't recall anything about changing existing behavior. Looks to me like we just disallowed some stuff that was formerly allowed for non-default character. Namely character(?) :: actual(2)*40 call sub(actual(1)(1:4)) ... subroutine sub(dummy) character(?) :: dummy(20)*4 Perhaps this is all covered elsewhere, but I'm too tired to scan for it. Just looking locally, it looks to me like a change. Issue 120 - C strings Aren't we going to say something more about C strings somewhere? Possibly in the section on C arrays, or possibly in a dedicated section. Even if we think it all follows from what we now have, I'd certainly think an example appropriate, with xrefs to the relevant sections. And then 16.2 might use a pointer to the example because its comment that Table 16.1 applies only for characters of length 1 invites the obvious question. Paper 98-238R2, enums Issue 115 - enums Added per passed edits. Plus I added probably more of my commentary than the original text. Paper 98-213r4, status error msgs Issue 116 - status error msg description Isn't this awfully detailed for a general description? I'd rather see something much more general and descriptive here. I notice that the word "error" doesn't even appear in the text, even though it is part of the procedure name. We have the exact keyword names, but not a word of categorization - I'd reverse that. Issue 117 - status error message details The detailed edits for STATUS_ERROR_MSG have yet to be completed. There has also been some debate about whether to keep it as a subroutine or make it a new specifier in the i/o and memory allocation statements. Misc Issue 118 - argument lengths in date_and_time The mailing list discussion seems to have given a fairly consistent answer to my proposed interpretation question about the lengths of the date, time, and zone arguments of date_and_time; f90/f95 is to be interpreted as requiring the actual argument to be of at least the length specified. I'd think this would be clearer if the phrase "in order to conatin the complete value" were just stricken (3 times). But I still wonder whether we wouldn't better extend f2k to allow shorter actual arguments with the obvious interpretation (truncating the returned result). Issue 119 - brackets for array constructors Now that we have square brackets in the character set, are we going to use them as an alternative form for array constructors? It is conventional math notation, a common Fortran extension, also used in other languages (Matlab for example), and a lot easier for the human to read than the 2-character form with slashes and parens. It would also answer a common user question..plus some questions that keep comming up about places in the standard where we use the [] mathematical notation. As far as I'm aware, the only reason array constructors weren’t like this all along is that the brackets weren’t in the character set. P.S. Umm, that is I thought we had the square brackets. But I can't find them in the draft. The 010 document shows edits as being in 98-119r1. I can't even find a 98-119r1, and 98-119 has no edits. This MTE appears to have been forgotten. IV. EDITORIAL CHANGES IN OLD UNRESOLVED ISSUES This is cleanup to get all of the explanatory text out of the 99-011 and into the J3 notes, plus to make sure that all J3 notes are numbered and have corresponding entries in 99-011. Issue 1 - text moved from 011 to a J3 note 1 in 9.5.1.11. Issue 2 - text moved from 011 to a J3 note 2 in 5.1.2.12. Issue 3 - text moved from 011 to a J3 note 3 in 9.5.4. Issue 4 - J3 note in 9.5.1.11 numbered as 4. Issue 5 - J3 note in 4.5.0 numbered as 5. Issue 6 - J3 note in 6.1.2 numbered as 6. Issue 7 - J3 note in 6.4.1.2 numbered as 7. Issue 8 - text moved from 011 to a J3 note 8 in 9.5.2. Issue 9 - text moved from 011 to a J3 note 9 in 5.1. Issue 10 - text moved from 011 to a J3 note 10 in 5.1. Issue 11 - text moved from 011 to a J3 note 11 in 15.2. Issue 12 - text moved from 011 to a J3 note 12 in 15.9.25 Issue 13 - text moved from 011 to a J3 note 13 in 14.7.5 Issue 14 - text moved from 011 to a J3 note 14 in 12.4.1.6. Issue 15 - J3 note in 5.2 numbered as 15 and extra added from 011. Issue 16 - J3 note in 5.2 numbered as 16 and extra added from 011. Issue 17 - J3 note in 4.5.3 numbered as 17. Issue 18 - J3 note in 4.5.3 numbered as 18. Issue 19 - J3 note in 4.5.6 numbered as 19. Issue 20 - J3 note in 7.5.2 numbered as 20 and extra added from 011. Issue 21 - J3 note in 14.1.2.5 numbered as 21 and extra added from 011. Issue 22 - text moved from 011 to a J3 note 22 in 15.9.22 Issue 121 - J3 note in 5.2 numbered as 121.