J3/97-223R1 Date: September 3, 1997 To: J3 From: Craig T. Dedo Subject: Interoperability with C - Response to PDTR This report is the collection of all of the comments from members of J3, the US Fortran standards committee, on the PDTR on Interoperability with C. The latest version of this document is paper number ISO/IEC JTC1/SC22/WG5 N1277 (a.k.a. NCITS/J3/97-154). There are many open issues, editorial flaws, and serious defects. We have broken the issues into three categories: 1) those that we absolutely cannot accept without change; 2) those we feel need serious attention, and another round of review; and 3) editorial issues. Category 1 Comment 1. 1.5 Is a processor permitted to make accessible entities in the ISO_C intrinsic module or other modules that are not defined by this PDTR? If so, the names may conflict with the name of a user-defined entity. This is similar to the issue Fortran has with permitting a standard-conforming processor to define intrinsic procedures that are not specified by the standard. Comment 2. 1.5, paragraph after Note 1.1 Section 1.5 of DIS 1539-1 states that a processor conforms if it "contains the capability to detect and report the use within a submitted program unit of an additional form or relationship that is not permitted by the numbered syntax rules or their associated constraints". How should a conforming processor handle the additional forms and relationships specified by this PDTR? Comment 3. 3, the whole section If this section is intended to be the technical specification, then it should be written in the same form and with the same precision of terminology as the Fortran 95 standard, particularly since the edit (in Section 4) for page 292 says that section 3 is to simply be inserted into the Fortran standard as the new section 16. Comment 4. 3.1, 1st paragraph after Note 3.3 It says that an implementation may support all or parts of the contents of the corresponding C standard header. This seems to be a large hole in portability if vendors can not only choose which headers they support but can also determine the contents of the headers. Comment 5. 3.2, Note 3.6 Although the C standard requires that a C program not use two external names that are distinguished only by case, this TR needs to require a Fortran processor that does not support lower case letters to have some facility to enable the mapping to the C external name. For example, int MyCFunc(void) {} INTERFACE BIND(C,NAME='MYCFUNC') INTEGER(C_INT) FUNCTION F() USE ISO_C END FUNCTION F END INTERFACE If the C processor preserves the case in the bind name for MyCFunc, the Fortran processor needs some way of getting to that name. It should probably be a method that's not specified in the TR, but still required. Comment 6. 3.3.1, Note 3.10 Support for unsigned integers is still confusing. The paragraph after Note 3.10 notes that unsigned C types have the same size and alignment as their signed counterparts. Given that the unsigned C types have the same representation as their associated signed types, there shouldn't be a need for the unsigned kinds, since there's no real support in Fortran for unsigned values. Comment 7. 3.3.2 The first paragraph of this section states that ISO_C_FLOAT_H module shall provide a module with *constants* for the numeric limits provided by the header. But most of the macros in do not have to be constants. They can expand into function calls for example. So, a module could not reliably provide constants if the C implementation decided to delay floating-point C characteristics until runtime. Comment 8. 3.3.4, Note 3.15 In the sentence "Consequently, a NAME= clause in a BIND(C) specification within a derived type definition is not allowed." should either be a constraint or a rule in prose in normative text. Notes are not normative. Comment 9. 3.3.4, 3.3.6, pp. 15, 17 As currently defined, the PDTR only supports the concepts of arrays of characters and pointers to type char. There really is no easy, straightforward, and to a Fortran programmer, intuitive way of handling CHARACTER data. This is especially true when a Fortran programmer is trying to pass a CHARACTER variable, array element, or substring to a C procedure which expects a C-style null- terminated string. Several commercial compilers already offer a transformational function, usually called CSTRING, which takes a Fortran CHARACTER scalar data object and transforms it into a C-style null-terminated string. The PDTR should include such a capability. Comment 10. 3.3.6, Note 3.20 Note 3.20 suggests that sequence association could be used to circumvent the problem that C permits 12 array-specs, while Fortran supports 7 array dimensions. We assume that this is suggesting that the rank specified for the dummy argument in the interface block would be seven or less, while the C array had 8 or more array-specs. If this is correct, it conflicts with the normative text in the paragraph that follows the note, which states the extents in the Fortran are those specified in the corresponding C array declarators (in reverse order). We read that as requiring the ranks to be the same. If they are not required to be the same, sequence association needs to be explicitly permitted, and the rules must be spelled out. Comment 11. 3.3.7, C_ADDRESS, C_DEREFERENCE, C_INCREMENT The argument to C_ADDRESS should be required to have the TARGET attribute; failing to require this severely hinders a processor's ability to perform optimization. Comment 12. 3.3.7, C_DEREFERENCE and C_INCREMENT Is the type of the MOLD argument specified permitted to be different from the type of the object from which the pointer was derived? Is C_INCREMENT permitted to specify an increment value that causes the dereference to exceed the bounds of an array? A user might expect to be able to do this in a case like the following: INTEGER, TARGET :: T1, T2 COMMON /COM/ T1(1), T2(1) PRINT *, C_DEREFERENCE(C_INCREMENT(C_ADDRESS(T1), T1, 1), T1) END Comment 13. 3.3.7, Note 3.24 The situations in which a pointer becomes "stale" need to be specified. This should be similar to the list of events that cause variables to become undefined (14.7.6 of 1539-1). That is, it is true of many more instances than just automatic objects. Why are automatic objects the only ones mentioned? The additional text added to clarify this point should be normative rather than informative. Comment 14. 3.3.7, C_DEREFERENCE description The description of case (iii) says that a dereference of a C_CHAR_PTR returns the whole string. Generally in C, a dereference of a character pointer only references a single character. If C_DEREFERENCE by definition always returns the whole string (like a C char pointer referenced in, say, strcpy()), then how does one use a C char pointer (from the Fortran side) to mimic the usual reference to only a single character? Comment 15. 3.3.7, C_DEREFERENCE - Result value Case (i) For the following example: integer(c_int) :: type(20) print *, C_DEREFERENCE(PTR, TYPE) is MOLD_T considered to be "int" or "int[20]"? This makes a significant difference in the meaning. Comment 16. 3.3.7, after C_DEREFERENCE A C_SET_DEREFERENCE (say) subroutine is desirable. This would provide a method of setting a value through a pointer. Comment 17. 3.3.9, R1606 The syntax of the leads to an ambiguity in fixed source form. One may name a pointer "TYPEXID" and one may have an array named "INTEGER" that has the TARGET attribute. Even in the presence of the ISO_C module, TYPE XID => INTEGER(c_ulong) could easily be a pointer assignment statement. One possibility is to require the "::" in fixed source form but this doesn't seem to be the optimal solution since the Fortran standard has no similar rule. Also, it might be a good idea to permit a list of entities to be declared in a single . For example, type :: t1 => integer, t2 => real And finally, the proposed syntax might cause people to confuse the objects declared with structures. We would like a keyword other than TYPE to be considered to call attention to the fact that the has different semantics. Comment 18. 3.3.9, second constraint Can the be the same as a variable name? a common block name? a procedure name? the name of a named constant? The second constraint isn't sufficient. The needs to be added to the list of local entities of class (1) in 1539-1 (14.1.2). Comment 19. 3.3.9, paragraph after Note 3.28 The second sentence states: If the aliased is an intrinsic type, a for shall contain a single , which shall be assignment compatible with that intrinsic type. The use of the term is misleading, since the value is not necessarily a structure. Why should the become a derived type if the is an intrinsic type? This doesn't make any sense for either Fortran or C (and is not like C; a typedef that names an intrinsic type does not suddenly create a struct). Perhaps a new non-terminal symbol (, for example) is needed. In addition, the meaning of this constructor is unclear, especially for intrinsic types; what is the value of the expression, what is its type? Creating a new name for an intrinsic type would be a generally useful feature. We don't understand why the type alias needs to be a derived type if the type spec is for an intrinsic type and we think this seriously limits the usefulness and generality of this statement. Note also that the first sentence of section 3.4.1 says "shall be a type alias for the implementation-defined integer type". We think a Fortran user would be very surprised that a type alias for an integer type is a derived type. Comment 20. 3.4.3 If a NULL constant is being defined, why is C_ISNULL needed? And where does the value C_NULL come from? If this is defined later, there should be a forward reference here. If C_ISNULL is also going to be kept, why does the description of C_ISNULL compare the PTR argument to zero instead of to NULL? Comment 21. 3.5.1.1, second paragraph This states that if no is present, the Fortran processor's rules are used to generate the external entry. Is this helpful? This means the user can't do anything portably if they don't specify the . Why not specify that it's treated as if was present with the value equal to the or , with any lower-case letters converted to upper-case? Comment 22. 3.5.1.2 This section appears to allow a "pointer to double" (and others, like "int *") to be passed as an argument to a C function, but the function itself cannot (portably) return a "pointer to double" value. This seems like a pretty limiting restriction. If the Fortran translator must somehow 'know' about pointers to basic types and pointers to structure types, then it seems like there is no technical reason why a C function cannot return a pointer to all of these types. Comment 23. 3.5.1.5, After 4th bullet Add a new bullet "A function result shall not be an array." Comment 24. 3.6 Some edits are needed to tie these objects in with the other global entities in 14.1.1 of 1539-1. One difference between these and other global entities is that it's not the name that is global, but the value specified by the . Is the value of the permitted to be the same as the name of any other global entity? Comment 25. 4, New clause 16 This indicates that section 3 could be placed into IS 1539-1 almost unchanged. However, section 3 is not currently in a state that that could be done. For example, it would not be appropriate for Note 3.1 to appear in IS 1539-1. Also, the section contains rules and explanatory material that doesn't necessarily belong in a new section 16. For example, in 3.3.4, the first paragraph after Note 3.15 states "The POINTER is not allowed because there is not C type whose corresponding Fortran type has the POINTER attribute." This more properly belongs in the edits to section 4.4.1 of IS 1539-1 as a constraint. Another example is the definition of the BIND statement in 3.2 rather than adding it as an edit to section 4 of IS 1539-1. Comment 26. General comment Let's get a little philosophical. How can a vendor know if they conform to this TR and whose "fault" is it when a mixed language program fails? The intent seems to be one of giving Fortran programmers access to the operating system, graphics libraries, C language libraries, etc. However, there's no guarantee that these routines are written in C! They could easily be written in assembly. It's not uncommon for parts of the Standard C Library to be written in assembly. The C standard doesn't require that they actually be written in C. Consider this scenario: Vendor A provides a "standard conforming" C compiler for architecture X Vendor B provides a "standard conforming" Fortran compiler for architecture X A mixed-language program fails Now, is it the Fortran vendor's "fault" if the C compiler is validated? That is, the C function works fine when called from C so it must be the Fortran compiler's problem. This seems like dangerous logic to get into. The best that can be done here may be to make this an informative annex because there's no way to seriously check conformance or to arbitrate resolution when mixed language programs fail. Unless the Fortran committee wants to say if the function works when called from C then it must be a Fortran problem. Now, if it can be the C compiler's fault then we recommend communication be made with WG14/J11 to make sure the C committee agrees with the responsibility that has just placed upon their shoulders. Since the document chooses not to address mixed language I/O, every Fortran programmer wishing to call a C function cannot put a "printf" or "fprintf" statement into their C function as a means of debugging their code. It is quite common in C to use "fprintf(stderr, .....)" to issue diagnostics when a function has been called incorrectly. It sounds like any function a user might want to call from Fortran had better not do that sort of thing. The same is true with the "assert" macro. This seems to me to be a serious limitation for any mixed language program, especially if you want to call an existing library routine. Exactly what routines are I/O routines? Is it some or all of the routines defined in the standard header ? For example, calling the "tmpnam" function seems totally innocuous. What about "sprintf" which is defined in but doesn't really do any output to a file? What about the "assert" macro? How about the "system" function? If an X-Windows routine pops up a window on the screen and asks the user to enter their name, is that considered to be I/O? Category 2 Comment 27. 3.1, Note 3.2 The note says that not all entities contained in are required to be supported in ISO_C_STDDEF_H. Who chooses what is supported and what is not? Is this implementation-dependent? Comment 28. 3.1, Paragraphs following Note 3.2 Should this document mandate the names of these modules without any specification of the contents? It's potentially confusing. Comment 29. 3.2, R1601 Why are the LANG= and NAME= specifiers specified as being optional but PRAGMA= is required for each specified pragma? Comment 30. 3.2, first constraint after R1604 Does the value of include leading or trailing blanks? We assume so, but we would like this clarified since blanks are ignored in determining the value of an I/O specifier. Comment 31. 3.3, Note 3.8 It states that "enum" types are not integer types (but rather integral types). Defect Report #067 asks the question about which category enumerated types falls into. The reply starts out by saying: "Signed integer type", "unsigned integer type", and plain "integer type" are used interchangeably with "signed integral type", "unsigned integral type" and "integral type" in the C Standard. So, an enumerated type must map onto one of the integer types, but the implementation need not reveal what the underlying type really is. I don't think you want to provide a binding to enum types in the TR, but Note 3.8 should be corrected. The problem is that there is no way to tell what the underlying integral type really is. Comment 32. 3.3.1, the list of C basic types and Fortran intrinsic types The names of the named constants should be spelled out so that the names have the same spellings as the C data types. For example, C_SHRT should be C_SHORT. We understand that Note 3.9 has the rationale for choosing the names, but Fortran programmers are not going to be looking in these headers. They are going to be somewhat familiar with the C data types so the terms used to describe these C data types should use the same words. Comment 33. 3.3.1, Note 3.10 It states that the type "char" is not an integer type. This is an incorrect assertion for the same reason as cited for "enum" above. Comment 34. 3.3.1, Note 3.12 The TR should not give suggestions about possible extensions. Comment 35. 3.3.2, third paragraph This indicates that the values made accessible shall conform to the requirements of the C standard. What if that requires representation of values that are not model numbers in the Fortran model, e.g. -2**31? Comment 36. 3.3.3 Perhaps we could provide partial support for enum types with integer kind parameters named C_SCHAR_ENUM (for enums whose value is within the signed char range), C_SHORT_ENUM (for those whose value is within the short int range), etc. This may help in almost all cases, but does not necessarily solve the problem, since the C processor may not use straightforward rules in determining the representation for the enum type. Or perhaps a SELECTED_ENUM_KIND(LOW_ENUM, HIGH_ENUM). Of course, if the suggestion that enums not be supported is taken, this comment can be ignored. Comment 37. 3.3.4, paragraph following Note 3.15 The first sentence should be a constraint. Comment 38. 3.3.6, Last paragraph Change "may build on any" to "may build on either". On the other hand, what does it mean for the Fortran binding to "build on" the C type? How can Fortran "build on" double *? Should this paragraph be made into a note? Comment 39. 3.3.6 Should mismatched array shapes be prohibited? It's going to be easy for the programmer to get confused between row-major and column-major subtleties. Comment 40. 3.3.7, second paragraph In which module is C_NULL defined? Also, where are the C_ISNULL, C_ADDRESS, et al. functions defined? Comment 41. 3.3.7, Description of C_ISNULL Change "Compares PTR to zero" to "Compares PTR to the appropriate C null pointer". (or something like that). Should this function be elemental rather than transformational? Is the function even necessary - why not provide operator(==) and operator(/=) instead? Comment 42. 3.3.7, C_ADDRESS, C_DEREFERENCE, C_INCREMENT Some of the arguments are permitted to be of any type. These should probably be restricted to be of types that are permitted in references to C procedures. In addition, should zero-sized objects be prohibited from appearing? Comment 43. 3.3.7, C_ADDRESS Why is the result value undefined if OBJ is of one of the pointer types and C_ISNULL(OBJ) is true? Shouldn't this procedure be returning a pointer to OBJ rather than a pointer to the objects OBJ points to? Comment 44. 3.3.7, C_DEREFERENCE - Result value Case (i) Change "*((MOLD_T *) PTR) where PTR is ... PTR." to "*((MOLD_T *) PTR), where PTR is ... PTR, and MOLD_T is the type of MOLD." Comment 45. 3.3.7, C_DEREFERENCE - Result value Case (ii) The description of the MOLD argument indicates that the MOLD argument shall be present if PTR is of type TYPE(C_STRUCT_PTR), but Case (ii) indicates that the result has the value of *(PTR), rather than expressing it as *((MOLD_T *)PTR). Shouldn't cases (ii) and (iii) be combined? Comment 46. 3.3.7, C_DEREFERENCE - Result and Example Case (iii) Change "ASCII NUL" to "NUL" (or whatever term is used to describe '\0' in the C standard - we don't want to require support for ASCII.) The PDTR should say something about '\0' being the same as CHAR (0, KIND=C_CHAR). Comment 47. 3.3.7, C_DEREFERENCE - Result value Case (iii) The dependence on the string being NUL-terminated seems unfriendly. There's no requirement that char * point to a C string. Perhaps it should return the value of (char *) ('h' in this case), making it more consistent with the other two cases. A separate set of procedures could be defined to handle the string case. Comment 48. 3.3.7, C_INCREMENT - Result value Change "(PTR *)((MOLD *)PTR+N) where PTR is . . . PTR." to "(PTR *)((MOLD_T *)PTR+N), where PTR is . . . PTR, and MOLD_T is the type of MOLD." Comment 49. 3.3.8 This section seems to imply that a C definition like: int func(int n, float x); int func(n, x) int n; float x; { return n + x; } is not allowed because the definition uses old-style (even though a prototype is in scope). Is this intended? Seems like this should say that the "type of the definition includes a function parameter list" and not focus on the declarator. Comment 50. 3.3.9, R1606 The meaning of the on the needs to be specified. Compare to p.40, lines 39-41 of 1539-1. Comment 51. 3.3.9, first paragraph after constraints after R1606 Rule R502 of IS 1539-1 needs to be extended to permit TYPE() as a . Comment 52. 3.3.10 If we're not specifying the meaning of volatile at all, we shouldn't permit a Fortran entity to be associated with such an object. Comment 53. 3.3.10, last paragraph Instead of specifying that if a C object of a const-qualified type is used in a way that violates the C standard, the object becomes undefined, shouldn't we specify that such an object is not permitted to become redefined? Comment 54. 3.3.11 Why is there a restriction on "register" being present for parameter declarations? Some rationale is needed. Comment 55. 3.4.2, Argument As with the arguments to C_ADDRESS, et al., should the type be restricted? Should the TYPE argument be required to be of a type that has the BIND(C) attribute or of an intrinsic type that has a kind parameter defined in the ISO_C module? After "it shall be allocated." add "It shall not be an assumed-size array.". Comment 56. 3.4.2, the Example The example uses the kind type parameter C_CHAR to precede a character constant. Is there any implication here that C_CHAR implies the character constant is terminated by the null character? The Argument description for C_SIZEOF states that EXPR may be of any type. Does this mean that a default character constant can be passed to it or is there some unstated expectation that it must be of type C_CHAR? Comment 57. 3.4.3 Why are all the new intrinsic functions prefixed by "C_" except for OFFSETOF? This seems to be quite inconsistent. Comment 58. 3.4.3, Description What does "its structure" mean? For example, in a structure reference of the form OUTER%MIDDLE%COMP is "its structure" defined to mean OUTER or OUTER%MIDDLE? Seems like it should be OUTER%MIDDLE since COMP is a component of OUTER%MIDDLE, but we can easily imagine that a user might want to know the offset of COMP within OUTER or within OUTER%MIDDLE. Does the specification of the TYPE argument (which really should be STRUCTURE because we're talking about the offset within the object named with a structure name, not with a derived type name) allow C_OFFSETOF(OUTER, OUTER%MIDDLE%COMP) as well as C_OFFSETOF(OUTER%MIDDLE, OUTER%MIDDLE%COMP) If there is no intent of allowing the second case then the first argument is superfluous. Comment 59. 3.5, first paragraph This states that an explicit interface is required for a procedure defined by means of C, and that it have the BIND(C) attribute. Currently 1539-1 doesn't require this, so this requirement would cause conforming Fortran 95 programs to be non-conforming with respect to this TR. Comment 60. 3.5.1.2, Note 3.34 If the second sentence is "implying" a rule, the sentence should be moved out of the note and turned into a rule in normative text. Comment 61. 3.5.1.2, second bullet Delete second bullet. It is confusing in a list of supported items and how they are supported. Also, delete sentence that reads "All other C pointer types are not supported." Instead, insert before 1st paragraph of 3.5.1.2, something like: "The return type of the C function shall be void, a basic type, a structure type, pointer to void, pointer to struct or pointer to char. The return type is not permitted to be an enumeration type, a union type or any other C pointer type." Comment 62. 3.5.1.3, R1607 As in the BIND attribute, why is "PRAGMA=" required? Comment 63. 3.5.1.3, the constraint for R1607 Why force a user to write a zero-length string? If it doesn't apply then just don't specify it. Comment 64. 3.5.1.3, Constraint after R1608 Why not permit blanks that are not significant as is done with I/O specifiers? Comment 65. 3.5.1.3, second paragraph after R1608 Change "A "*" character in the " to "If the value of the is "*", it" (Of course, the suggested modification will be affected by the following comment.) Should some more suggestive value for the be used other than '*' and ''? Reword the sentence that reads "A "*" character in the. . . "pointer to T"" As written, it implies that "pointer to T" is a Fortran type, whereas there are no pointer types in Fortran. Comment 66. 3.5.1.4, second bullet of first bulleted list and fifth bullet of the second bulleted list Reword in a way that is consistent with the suggestion for 3.5.1.2, second bullet. Comment 67. 3.5.1.4 It is unclear how arrays are passed to C. Specifically, C is row major and Fortran is column major, but the TR states that the Fortran interface "shall declare the type corresponding to the C type T, a DIMENSION attribute corresponding to the C array declarator, ...". If the C parameter is declared: int A[2][3] then 3.3.6 states that the corresponding Fortran declaration is: INTEGER, DIMENSION(3,2) :: A but what happens if the (for all practical purposes) identical declarations of: int (*A)[3] or int A[][3] are used? Should the corresponding Fortran declaration be: INTEGER, DIMENSION(3,*) :: A It is not clear from the TR whether this is correct. Comment 68. 3.5.1.5, 4th bullet Change "A dummy argument or function result" to "A dummy argument". Comment 69. 3.5.2.1 Change "If the dummy argument" to "If a dummy argument of a procedure with the BIND(C) attribute" in the first sentence of each paragraph. Comment 70. 3.5.2.1, second sentence (beginning "It shall be") What does "It" refer to? The dummy argument or actual argument? Same comment for second sentence of second paragraph following Note 3.40 and for the second sentence of the paragraph following Note 3.42. This same sentence following Note 3.42 contains the phrase of type TYPE(C_VOID_PTR) which compares equal to NULL. Can it be compared equal to NULL or must it be passed to C_ISNULL? Does the font indicate the C NULL? If so, why? Why not specify that it must be equal to the Fortran NULL constant? The same question applies to "It" in the second sentence of paragraph 3. Comment 71. 3.5.2.1, 3rd paragraph The sentence that begins "ASSIGNMENT(=) for the types. . . " seems to describe something that is unnatural. The entire concept that conversions for actual arguments happen implicitly on procedure references is foreign to Fortran, but support for implicit defined assignment even when the defined assignment is not accessible is very strange. In addition, what happens when the user redefines assignment for these types? Comment 72. 3.5.2.2 Change "If a dummy argument" to "If a dummy argument of a procedure with the BIND(C) attribute" in the first sentence of each paragraph. Comment 73. 3.5.3 The handling of seems clumsy. Why is the operator specified as "OPERATOR(//)" instead of just "//"? This form is used for interface blocks and makes one think that an interface block for the operator // must be provided somewhere. A suggested alternative would be to define a descriptive procedure in ISO_C_STDARG_H that has a variable number of arguments (similar to MAX and MIN). For example, call sub(va_list(i,j,k,a(17))) call sub(va_list(i,r)) If the first item in the list must always be VA_EMPTY, why make the user write it? The compiler can just construct the VA list this way. Comment 74. 3.5.3 Since VA_LIST must be a derived type, it seems like the corresponding C type must be a structure type. Many implementations of va_list use a pointer instead. This could be a problem if, say, the minimum size for any derived type is 64-bits but a pointer is 32-bits. Comment 75. 3.6 It should be noted when such a variable becomes defined (as is done in 14.7.5 of 1539-1 for variables which are initialized). Comment 76. 3.6, first bullet after Note 3.51 Change "No initialization shall appear in the ." to "initialization shall not appear in an in a for a variable with the BIND(C) attribute." Comment 77. 3.6, second bullet after Note 3.51 Change "ALLOCATABLE, PARAMETER or POINTER shall not be specified." to "The variable shall not * have the ALLOCATABLE, PARAMETER or the POINTER attribute * be an automatic object * be a function result variable." Comment 78. 3.6, last paragraph before Note 3.52 Change "If two or more. . . are accessible in a scoping unit" to "If two or more. . . " Comment 79. 3.6, last paragraph It's not clear what this paragraph is saying. Is it talking about things like errno? Also, what does it mean to say that "The Fortran processor is not required to guard such behavior"? Comment 80. 3.7, paragraph preceding Note 3.54 The last sentence is describing a comparison to (apparently) the C NULL again instead of using the Fortran NULL or C_ISNULL. Comment 81. 4, 2nd constraint in edits for page 38 Change "the same " to "the same ". (At least, we think that was what was intended.) Comment 82. 4, edits for page 38 Is BIND(FORTRAN) permitted to appear in a derived type definition? If so, what effect does it have? Should the SEQUENCE statement still be prohibited for that case? Comment 83. General comment C9X is due to hit the streets in 1999. So, by the time this TR makes it into a Fortran standard, there will be a new (and hopefully improved) C Standard. The TR should attempt to align itself with C9X. Things to consider: new keywords: restrict, complex new headers: is likely to be added soon external names: 31 characters, mixed case new types: long long, unsigned long long, float complex, double complex, long double complex, restricted pointers, variable length arrays Category 3 Comment 84. 1.4, item 1 Change "Mixed-Language Input and Output" to "Mixed-language input and output". Comment 85. 1.4, item 4 Change "and some pointer types" to ", some pointer types, and bit fields". Comment 86. 1.5 Delete "first-class" (twice) {we don't use this kind of terminology in the standard} Comment 87. 2, first paragraph What is meant by "the standard (de-facto or de-jure) computing environment? What standard? A Macintosh in someone's home does not generally have a C compiler on it and yet it seems to be a productive computing environment. Comment 88. 2, second paragraph after bulleted list Change "environment: Many" to "environment - many". Also in this paragraph in the sentence beginning "Due to the difficulties...": People are not moving to C because of the difficulties of producing a standard for communications between Fortran and C; they are moving to C because there is no such standard at all or because it is more "natural" to write the application in C. Comment 89. 3, Note 3.1 Given the general statement on section 3 (in category 1), this note should be deleted. Comment 90. 3.1, the bulleted list Who is going to provide these standard modules and by what mechanism are they going to be kept current with the C standard? Comment 91. 3.1, second bullet in list Is "common definitions" a C term? If not, a different term should be used to avoid confusion with the Fortran meaning of the word "common". Comment 92. 3.1, First paragraph after Note 3.2 Change "facilites" to "facilities". Comment 93. 3.1, 1st paragraph after Note 3.3 "name" appears in italics once, but other occurrences are not italicized. Comment 94. 3.2, the first paragraph and throughout the remainder of the document Each section reference should be qualified so the reader knows what document the section number is relative to. For example, in the first paragraph of 3.2, section 1.4 could refer to this document or to the Fortran 95 standard. Comment 95. 3.2, paragraph following the constraints following R1604 Change ", this" to ". This". Comment 96. 3.2, 1st paragraph after Note 3.6 Change "which" to "that". Comment 97. 3.2, Constraint after R1605 Change "which" to "that". Comment 98. 3.3, Note 3.7 Change "are supported, see" to "are supported; see". Comment 99. 3.3, paragraph following Note 3.7 Change "define object types" to "define data types". Comment 100. 3.3, Paragraph after Note 3.8 Change "Fortran types, access" to "Fortran types; access". Change "C datatypes: Derived" to "C data types. Derived". Change "recursively applied," to "recursively applied, and". Comment 101. 3.3.1, first paragraph Change "and real types: The intrinsic" to "and real types. The intrinsic". Comment 102. 3.3.1, the list of C basic types and Fortran intrinsic types The names of the kind parameters should be listed before specifying which data types correspond to which C data types. Comment 103. 3.3.1, Note 3.11 It's not clear whether this note is suggesting things that an implementation needs to do to support the unsigned types or something the user needs to do. Comment 104. 3.3.3, before Note 3.13 Change "implementation-defined: It" to "implementation-defined. It". Comment 105. 3.3.4, Last sentence of paragraph after Note 3.14 Replace with "A shall not be specified for any component of a derived type that has the BIND(C) attribute." Comment 106. 3.3.4, Note 3.15 Change "the Fortran member objects" to "the Fortran derived type components". Change "way: The" to "way. The". Comment 107. 3.3.4, second paragraph following Note 3.15 This is the first time TYPE(C_STRUCT_PTR) has been seen. This may confuse the reader, and cause them to search back toward the front of the document to locate the definition of this term. It turns out that this term is defined later in the document. The term should either be defined before this reference or there should be a forward reference here to where this term is defined. Comment 108. 3.3.4, Note 3.16 Same point as above for TYPE(C_CHAR_PTR) in the example. Comment 109. 3.3.4, Paragraph after Note 3.16 Delete the sentence that begins "In either case, ...". It's not clear why the user might have thought that the length information would be stored in the structure. Comment 110. 3.3.5, Note 3.18 Change "union members: In" to "union members. In". Or just delete the note entirely. We shouldn't give suggestions as to how to write non-conforming code. Comment 111. 3.3.6, Note 3.21 Change "the transposition must be done by the user" to "one can use the RESHAPE intrinsic with the ORDER argument present". Comment 112. 3.3.7, C_ISNULL, C_ADDRESS, et al. Each of these functions should probably be in a separate little section (as is done for the Fortran intrinsic procedures). Comment 113. 3.3.7, second paragraph Change "are supported: The" to "are supported. The". Comment 114. 3.3.7, paragraph preceding "C_ISNULL(PTR)" Change "All C pointers" to "In a C program, all pointers". In the next sentence, insert "in Fortran" following "this comparison". Comment 115. 3.3.7, Result value description and Example for C_ISNULL The Fortran standard uses "true" and "false" for logical values in the descriptions of intrinsic procedures rather than ".TRUE." and ".FALSE.". Comment 116. 3.3.7, Note 3.22 It's not clear what the first sentence of this note is trying to say. Shouldn't it be sufficient to say that none of the operators is defined on these types. (We don't think it's really necessary to say even that much.) Comment 117. 3.3.7, C_DEREFERENCE - Example Case (iii) Change "character string of length 5" to "character string of length 6". (Is the length returned by LEN or strlen that is being discussed?) Comment 118. 3.3.7, Note 3.27, paragraph following the extern example The first sentence of the note should remain. The remainder of the note should be replaced with an example that would be valid. There is no guarantee that the representation of void * will be the same as the representation of char **. If this functionality is actually required, a C_CHAR_PTR_PTR type should be defined. Comment 119. 3.3.7, Last paragraph This last paragraph should be made informative. Comment 120. 3.3.9, first constraint after R1606 Change "1539" to "1539-1". (There are other instances as well.) Comment 121. 3.3.9, first paragraph after constraints after R1606 Change "interchangeable" to "interchangeably". Change "corresponding : entities" to "corresponding . Entities". Comment 122. 3.3.9, Note 3.29 Change "hidded" to "hidden". Comment 123. 3.3.10, last paragraph We think the sentence about a Fortran processor not being required to diagnose violations that take place while a C subprogram is executing can be deleted. Comment 124. 3.3.11, Note 3.30 Delete "(which is comparable to Fortran PRIVATE entities)". Comment 125. 3.4.1, Note 3.31 Why does this note exist? The result types of C_SIZEOF and OFFSETOF are explicitly described in the descriptions of these two new intrinsic functions. Comment 126. 3.4.3 Delete the comma in the section title. Comment 127. 3.4.3, 2nd paragraph Change "follwing" to "following". Comment 128. 3.4.3, Description Change "strucure" to "structure". Change both the second argument and the word "member" in the first sentence to the word "component". The Fortran standard uses "component", not "member". In Result Characteristics, "imlementation-defined" is misspelled (missing the "p"). Since the next section of the description does not capitalize the word "value", "Characteristics" should also not be capitalized. (This same capitalization change should be made in other intrinsic descriptions elsewhere in the document as well.) In Result value, delete the comma after "C standard)". Comment 129. 3.5.1, first paragraph Change "inluding" to "including". Comment 130. 3.5.1, Note 3.33 Change "parantheses" to "parentheses". Or just delete this note. It describes how a user might do something that is expressly prohibited by the normative text preceding the note. Comment 131. 3.5.1.1, first sentence Italicize "". Comment 132. 3.5.1.2, 1st paragraph after Note 3.34 Delete "The declaration of the function result variable shall be as follows:" Comment 133. 3.5.1.3, Constraint after R1608 Remove quotes around asterisk - they are not part of the value. Comment 134. 3.5.1.3, first paragraph after R1608 Change " this" to ". This". Comment 135. 3.5.1.4, second paragraph Delete "The Fortran declaration. . . as follows:". Comment 136. 3.5.1.4, sentence following Note 3.37 Change "of the C function" to "of a C function" and change "type: If" to "type. If". Comment 137. 3.5.1.4, 6th bullet of second bulleted list Change "funtion" to "function". Comment 138. 3.5.1.4, last paragraph Change "All other C pointer types are not supported." to "No other C pointer types are permitted." Comment 139. 3.5.1.5, 8th bullet Change "shall have an explicit interface, and that interface" to "shall have explicit interfaces, and those interfaces" Comment 140. 3.5.2.1, last sentence before Note 3.43 Rather than indicating that the actual argument has to obey the same set of restrictions that something else obeys, repeat the restrictions for this case. Comment 141. 3.5.2.1, Paragraph 3, last sentence. Change "is" to "are". Comment 142. 3.5.2.3 Delete this note and section. It should not be necessary to call the user's attention to this. Comment 143. 3.5.2.3 The first occurrence of the word "free" need not be in bold Courier since it is not referring to the free() function. Comment 144. 3.5.2.3 The phrase "to take care about" seems awkward. Comment 145. 3.5.3, first paragraph Change "procedure interfaces." to "procedure interface.". Comment 146. 3.5.3, Note 3.45 Delete this note. Each of Fortran and C is able to do things that the other cannot. Comment 147. 3.5.3, the bullet at the top of page 35 Change "to operands x1 of type" to "to operands x1 and x2 of type". In the last sentence of this bullet, change "x2," to "x2;". Comment 148. 3.6, first sentence after Note 3.51 Change "additonal" to "additional". Comment 149. 3.6, third bullet after Note 3.51 Is it necessary to mention that CHARACTER with assumed character length is not permitted? This should follow from the fact that it is not permitted to be a dummy argument or named constant. Comment 150. 3.6, last paragraph before Note 3.52 Change "They all refer to the same storage." to "All such variables are storage associated." Comment 151. 3.6, paragraph after Note 3.52 Is this paragraph necessary? Shouldn't this follow from the definition of storage association? Perhaps it should be made into a note if it's felt to be necessary. Comment 152. 3.7, paragraph preceding Note 3.54 Change "an MOLD" to "a MOLD". Comment 153. 3.7, Note 3.54 Change "allows to load X resources from command line arguments" to "allows X resources to be loaded from command line arguments". Comment 154. 4, edit for page xvi Change "defined by Fortran code" to "defined by a Fortran module program unit". Comment 155. 4, edits for page 48 Change "may only" (two occurrences) to "shall only". Change "which" to "that". Comment 156. 4, Annex D In most instances cross-references are left unqualified, so it is sometimes unclear whether the reference is to a section within the PDTR, a section in the Fortran DIS or a section in the ISO C standard. --------------2F6036A06165 Content-Type: application/postscript; name="97-223r1.ps" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="97-223r1.ps" %!PS-Adobe-3.0 %%Title: Interoperability with C - Response to PDTR %%Creator: Windows NT 4.0 %%CreationDate: 20:38 8/26/1997 %%Pages: (atend) %%BoundingBox: 9 9 606 776 %%LanguageLevel: 1 %%DocumentNeededFonts: (atend) %%DocumentSuppliedFonts: (atend) %%EndComments %%BeginProlog %%BeginResource: procset NTPSOct95 /NTPSOct95 100 dict dup begin/bd{bind def}bind def/ld{load def}bd/ed{exch= def} bd/a{currentpoint}bd/c/curveto ld/d/dup ld/e/eofill ld/f/fill ld/tr/trans= late ld/gr/grestore ld/gs/gsave ld/j/setlinejoin ld/L/lineto ld/M/moveto ld/n /newpath ld/cp/closepath ld/rm/rmoveto ld/sl/setlinewidth ld/sd/setdash l= d/g /setgray ld/r/setrgbcolor ld/s/stroke ld/t/show ld/aw/awidthshow ld/im /imagemask ld/MS{moveto show}bd/SF{findfont exch scalefont setfont}bd/SM{= cmtx setmatrix}bd/MF{findfont exch makefont setfont}bd/CM{/cmtx matrix current= matrix def}bd/B{M exch dup 0 rlt exch 0 exch rlt neg 0 rlt}bd/CB{B cp eoclip}bd/= EA{1 index 0/G0 put 4 string 1 1 4 -1 roll{3 copy neg exch cvs dup 0 71 put cv= n 3 -1 roll exch put}for pop}bd/rlt/rlineto ld/L2?/languagelevel where{pop languagelevel 2 ge}{false}ifelse def end def = %%EndResource %%EndProlog %%BeginSetup [{0 /languagelevel where{pop languagelevel 2 ge}{false}ifelse {1 dict dup/JobTimeout 4 -1 roll put setuserparams} {statusdict/setjobtimeout get exec}ifelse }stopped cleartomark [{240 /languagelevel where{pop languagelevel 2 ge}{false}ifelse {1 dict dup/WaitTimeout 4 -1 roll put setuserparams} {statusdict/waittimeout 3 -1 roll put}ifelse }stopped cleartomark /#copies 1 def [{ %%BeginFeature: *PageSize Letter statusdict /lettertray get exec %%EndFeature } stopped cleartomark %%EndSetup NTPSOct95 begin %%Page: 1 1 NTPSOct95 /PageSV save put 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate %%IncludeFont: NewCenturySchlbk-Bold [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS %%IncludeFont: NewCenturySchlbk-Roman [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 1 of 20)1978 293 MS (This report is the collection of all of the comments from members of J3,= the US Fortran)413 393 MS (standards committee, on the PDTR on Interoperability with C. The latest= version of this document)263 440 MS (is paper number ISO/IEC JTC1/SC22/WG5 N1277 \(a.k.a. NCITS/J3/97-154\). = There are many open)263 487 MS (issues, editorial flaws, and serious defects.)263 534 MS ( We have broken the issues into three categories:)263 629 MS ( 1\) those that we absolutely cannot accept without change;)263 72= 3 MS ( 2\) those we feel need serious attention, and another round of re= view; and)263 771 MS ( 3\) editorial issues.)263 818 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Bold MF (Category 1)263 913 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (Comment 1.)263 1008 MS n 234 2 263 1011 B f (1.5)263 1055 MS (Is a processor permitted to make accessible entities in the ISO_C intrin= sic)263 1102 MS (module or other modules that are not defined by this PDTR? If so, the n= ames)263 1150 MS (may conflict with the name of a user-defined entity. This is similar to= the)263 1197 MS (issue Fortran has with permitting a standard-conforming processor to def= ine)263 1244 MS (intrinsic procedures that are not specified by the standard.)263 1291 MS= (Comment 2.)263 1386 MS n 234 2 263 1389 B f (1.5, paragraph after Note 1.1)263 1433 MS (Section 1.5 of DIS 1539-1 states that a processor conforms if it "contai= ns)263 1480 MS (the capability to detect and report the use within a submitted program)2= 63 1528 MS (unit of an additional form or relationship that is not permitted by the)= 263 1575 MS (numbered syntax rules or their associated constraints". How should a)26= 3 1622 MS (conforming processor handle the additional forms and relationships speci= fied)263 1669 MS (by this PDTR?)263 1717 MS (Comment 3.)263 1811 MS n 234 2 263 1814 B f (3, the whole section)263 1858 MS (If this section is intended to be the technical specification, then it s= hould)263 1906 MS (be written in the same form and with the same precision of terminology a= s the)263 1953 MS (Fortran 95 standard, particularly since the edit \(in Section 4\) for pa= ge 292)263 2000 MS (says that section 3 is to simply be inserted into the Fortran standard a= s the)263 2047 MS (new section 16.)263 2095 MS (Comment 4.)263 2189 MS n 234 2 263 2192 B f (3.1, 1st paragraph after Note 3.3)263 2236 MS (It says that an implementation may support all or parts of the contents)= 263 2284 MS (of the corresponding C standard header. This seems to be a large hole i= n)263 2331 MS (portability if vendors can not only choose which headers they support bu= t)263 2378 MS (can also determine the contents of the headers.)263 2425 MS (Comment 5.)263 2520 MS n 234 2 263 2523 B f (3.2, Note 3.6)263 2567 MS (Although the C standard requires that a C program not use two external n= ames)263 2614 MS (that are distinguished only by case, this TR needs to require a Fortran)= 263 2662 MS (processor that does not support lower case letters to have some facility= to)263 2709 MS (enable the mapping to the C external name. For example,)263 2756 MS ( int MyCFunc\(void\))263 2851 MS ( {})263 2898 MS ( INTERFACE)263 2992 MS ( BIND\(C,NAME=3D'MYCFUNC'\) INTEGER\(C_INT\) FUNCTION F\(\))263 3040 = MS showpage %%Page: 2 2 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 2 of 20)1978 293 MS ( USE ISO_C)263 393 MS ( END FUNCTION F)263 440 MS ( END INTERFACE)263 487 MS (If the C processor preserves the case in the bind name for MyCFunc, the)= 263 582 MS (Fortran processor needs some way of getting to that name. It should pro= bably)263 629 MS (be a method that's not specified in the TR, but still required.)263 676 = MS (Comment 6.)263 771 MS n 234 2 263 774 B f (3.3.1, Note 3.10)263 818 MS (Support for unsigned integers is still confusing. The paragraph after N= ote 3.10 notes that unsigned)263 865 MS (C types have the same size and alignment as their signed counterparts. )= 263 912 MS (Given that the unsigned C types have the same representation as their as= sociated signed types,)263 1007 MS (there shouldn't be a need for the unsigned kinds, since there's no real = support in Fortran for)263 1054 MS (unsigned values.)263 1101 MS (Comment 7.)263 1196 MS n 234 2 263 1199 B f (3.3.2)263 1243 MS (The first paragraph of this section states that ISO_C_FLOAT_H module sha= ll)263 1290 MS (provide a module with *constants* for the numeric limits provided by the= )263 1338 MS ( header. But most of the macros in do not have to be= )263 1385 MS (constants. They can expand into function calls for example. So, a modu= le)263 1432 MS (could not reliably provide constants if the C implementation decided to)= 263 1479 MS (delay floating-point C characteristics until runtime.)263 1527 MS (Comment 8.)263 1621 MS n 234 2 263 1624 B f (3.3.4, Note 3.15)263 1668 MS (In the sentence)263 1716 MS ( "Consequently, a NAME=3D clause in a BIND\(C\) specification)263 181= 0 MS ( within a derived type definition is not allowed.")263 1857 MS (should either be a constraint or a rule in prose in normative text. Not= es are not normative.)263 1952 MS (Comment 9.)263 2046 MS n 234 2 263 2049 B f (3.3.4, 3.3.6, pp. 15, 17)263 2094 MS (As currently defined, the PDTR only supports the concepts of arrays of c= haracters and pointers to)263 2141 MS (type )263 2188 MS %%IncludeFont: Courier [42 0 0 -42 0 0]/Courier MF (c)359 2188 MS (h)384 2188 MS (a)409 2188 MS (r)434 2188 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (. There really is no easy, straightforward, and to a Fortran programmer= , intuitive way of)459 2188 MS (handling CHARACTER data. This is especially true when a Fortran program= mer is trying to pass a)263 2238 MS (CHARACTER variable, array element, or substring to a C procedure which e= xpects a C-style null-)263 2286 MS (terminated string. Several commercial compilers already offer a transfo= rmational function, usually)263 2333 MS (called CSTRING, which takes a Fortran CHARACTER scalar data object and t= ransforms it into a)263 2380 MS (C-style null-terminated string. The PDTR should include such a capabili= ty.)263 2427 MS (Comment 10.)263 2522 MS n 257 2 263 2525 B f (3.3.6, Note 3.20)263 2569 MS (Note 3.20 suggests that sequence association could be used to circumvent= the)263 2616 MS (problem that C permits 12 array-specs, while Fortran supports 7 array)26= 3 2664 MS (dimensions. We assume that this is suggesting that the rank specified f= or the)263 2711 MS (dummy argument in the interface block would be seven or less, while the = C)263 2758 MS (array had 8 or more array-specs. If this is correct, it conflicts with = the)263 2805 MS (normative text in the paragraph that follows the note, which states the)= 263 2853 MS (extents in the Fortran are those specified in the correspon= ding C)263 2900 MS (array declarators \(in reverse order\). We read that as requiring the r= anks)263 2947 MS (to be the same. If they are not required to be the same, sequence assoc= iation)263 2994 MS (needs to be explicitly permitted, and the rules must be spelled out.)263= 3042 MS showpage %%Page: 3 3 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 3 of 20)1978 293 MS (Comment 11.)263 393 MS n 257 2 263 396 B f (3.3.7, C_ADDRESS, C_DEREFERENCE, C_INCREMENT)263 440 MS (The argument to C_ADDRESS should be required to have the TARGET attribut= e;)263 487 MS (failing to require this severely hinders a processor's ability to perfor= m)263 534 MS (optimization.)263 582 MS (Comment 12.)263 676 MS n 257 2 263 679 B f (3.3.7, C_DEREFERENCE and C_INCREMENT)263 723 MS (Is the type of the MOLD argument specified permitted to be different fro= m the)263 771 MS (type of the object from which the pointer was derived? Is C_INCREMENT)2= 63 818 MS (permitted to specify an increment value that causes the dereference to e= xceed)263 865 MS (the bounds of an array? A user might expect to be able to do this in a = case)263 912 MS (like the following:)263 960 MS ( INTEGER, TARGET :: T1, T2)263 1054 MS ( COMMON /COM/ T1\(1\), T2\(1\))263 1101 MS ( PRINT *, C_DEREFERENCE\(C_INCREMENT\(C_ADDRESS\(T1\), T1, 1\), T1\)= )263 1149 MS ( END)263 1196 MS (Comment 13.)263 1290 MS n 257 2 263 1293 B f (3.3.7, Note 3.24)263 1338 MS (The situations in which a pointer becomes "stale" need to be specified. = This)263 1385 MS (should be similar to the list of events that cause variables to become)2= 63 1432 MS (undefined \(14.7.6 of 1539-1\). That is, it is true of many more instan= ces than)263 1479 MS (just automatic objects. Why are automatic objects the only ones mention= ed?)263 1527 MS (The additional text added to clarify this point should be normative rath= er)263 1574 MS (than informative.)263 1621 MS (Comment 14.)263 1716 MS n 257 2 263 1719 B f (3.3.7, C_DEREFERENCE description)263 1763 MS (The description of case \(iii\) says that a dereference of a C_CHAR_PTR = returns)263 1810 MS (the whole string. Generally in C, a dereference of a character pointer = only)263 1857 MS (references a single character. If C_DEREFERENCE by definition always re= turns)263 1905 MS (the whole string \(like a C char pointer referenced in, say, strcpy\(\)\= ), then)263 1952 MS (how does one use a C char pointer \(from the Fortran side\) to mimic the= usual)263 1999 MS (reference to only a single character?)263 2046 MS (Comment 15.)263 2141 MS n 257 2 263 2144 B f (3.3.7, C_DEREFERENCE - Result value Case \(i\))263 2188 MS (For the following example:)263 2235 MS ( integer\(c_int\) :: type\(20\))263 2330 MS ( print *, C_DEREFERENCE\(PTR, TYPE\))263 2377 MS (is MOLD_T considered to be "int" or "int[20]"? This makes a significant= )263 2472 MS (difference in the meaning.)263 2519 MS (Comment 16.)263 2613 MS n 257 2 263 2616 B f (3.3.7, after C_DEREFERENCE)263 2661 MS (A C_SET_DEREFERENCE \(say\) subroutine is desirable. This would provide= a)263 2708 MS (method of setting a value through a pointer.)263 2755 MS (Comment 17.)263 2850 MS n 257 2 263 2853 B f (3.3.9, R1606)263 2897 MS (The syntax of the leads to an ambiguity in fixed sourc= e form.)263 2944 MS (One may name a pointer "TYPEXID" and one may have an array named "INTEGE= R")263 2991 MS (that has the TARGET attribute. Even in the presence of the ISO_C module= ,)263 3039 MS showpage %%Page: 4 4 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 4 of 20)1978 293 MS ( TYPE XID =3D> INTEGER\(c_ulong\))263 393 MS (could easily be a pointer assignment statement.)263 487 MS (One possibility is to require the "::" in fixed source form but this doe= sn't)263 582 MS (seem to be the optimal solution since the Fortran standard has no simila= r rule.)263 629 MS (Also, it might be a good idea to permit a list of entities to be declare= d in)263 723 MS (a single . For example,)263 771 MS ( type :: t1 =3D> integer, t2 =3D> real)263 865 MS (And finally, the proposed syntax might cause people to confuse the objec= ts)263 960 MS (declared with structures. We would like a keyword other than TYPE to be= )263 1007 MS (considered to call attention to the fact that the has)= 263 1054 MS (different semantics.)263 1101 MS (Comment 18.)263 1196 MS n 257 2 263 1199 B f (3.3.9, second constraint)263 1243 MS (Can the be the same as a variable name? a common bloc= k name?)263 1290 MS (a procedure name? the name of a named constant? The second constraint = isn't)263 1338 MS (sufficient. The needs to be added to the list of loca= l)263 1385 MS (entities of class \(1\) in 1539-1 \(14.1.2\).)263 1432 MS (Comment 19.)263 1527 MS n 257 2 263 1530 B f (3.3.9, paragraph after Note 3.28)263 1574 MS (The second sentence states:)263 1621 MS ( If the aliased is an intrinsic type, a)263 1716 MS ( for shall contain a)263 1= 763 MS ( single , which shall be assignment compatible with that)263 1= 810 MS ( intrinsic type.)263 1857 MS (The use of the term is misleading, since the val= ue is)263 1952 MS (not necessarily a structure. Why should the become a)= 263 1999 MS (derived type if the is an intrinsic type? This doesn't make= any)263 2046 MS (sense for either Fortran or C \(and is not like C; a typedef that names = an)263 2094 MS (intrinsic type does not suddenly create a struct\). Perhaps a new non-t= erminal)263 2141 MS (symbol \(, for example\) is needed. In additio= n, the)263 2188 MS (meaning of this constructor is unclear, especially for intrinsic types; = what)263 2235 MS (is the value of the expression, what is its type?)263 2283 MS (Creating a new name for an intrinsic type would be a generally useful fe= ature.)263 2377 MS (We don't understand why the type alias needs to be a derived type if the= type)263 2424 MS (spec is for an intrinsic type and we think this seriously limits the)263= 2472 MS (usefulness and generality of this statement.)263 2519 MS (Note also that the first sentence of section 3.4.1 says "shall be a type= alias)263 2613 MS (for the implementation-defined integer type". We think a Fortran user w= ould)263 2661 MS (be very surprised that a type alias for an integer type is a derived typ= e.)263 2708 MS (Comment 20.)263 2802 MS n 257 2 263 2805 B f (3.4.3)263 2850 MS (If a NULL constant is being defined, why is C_ISNULL needed? And where d= oes)263 2897 MS (the value C_NULL come from? If this is defined later, there should be a= )263 2944 MS (forward reference here. If C_ISNULL is also going to be kept, why does = the)263 2991 MS (description of C_ISNULL compare the PTR argument to zero instead of to N= ULL?)263 3039 MS showpage %%Page: 5 5 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 5 of 20)1978 293 MS (Comment 21.)263 393 MS n 257 2 263 396 B f (3.5.1.1, second paragraph)263 440 MS (This states that if no is present, the Fortran processor's= rules)263 487 MS (are used to generate the external entry. Is this helpful? This means t= he)263 534 MS (user can't do anything portably if they don't specify the .= Why)263 582 MS (not specify that it's treated as if was present with the v= alue)263 629 MS (equal to the or , with any lower-case l= etters)263 676 MS (converted to upper-case?)263 723 MS (Comment 22.)263 818 MS n 257 2 263 821 B f (3.5.1.2)263 865 MS (This section appears to allow a "pointer to double" \(and others, like "= int *"\))263 912 MS (to be passed as an argument to a C function, but the function itself can= not)263 960 MS (\(portably\) return a "pointer to double" value. This seems like a pret= ty)263 1007 MS (limiting restriction. If the Fortran translator must somehow 'know' abo= ut)263 1054 MS (pointers to basic types and pointers to structure types, then it seems l= ike)263 1101 MS (there is no technical reason why a C function cannot return a pointer to= all)263 1149 MS (of these types.)263 1196 MS (Comment 23.)263 1290 MS n 257 2 263 1293 B f (3.5.1.5, After 4th bullet)263 1338 MS (Add a new bullet)263 1385 MS ( "A function result shall not be an array.")263 1432 MS (Comment 24.)263 1527 MS n 257 2 263 1530 B f (3.6)263 1574 MS (Some edits are needed to tie these objects in with the other global enti= ties)263 1621 MS (in 14.1.1 of 1539-1. One difference between these and other global enti= ties is)263 1668 MS (that it's not the name that is global, but the value specified by the)26= 3 1716 MS (. Is the value of the permitted to be the sa= me as)263 1763 MS (the name of any other global entity?)263 1810 MS (Comment 25.)263 1905 MS n 257 2 263 1908 B f (4, New clause 16)263 1952 MS (This indicates that section 3 could be placed into IS 1539-1 almost unch= anged.)263 1999 MS (However, section 3 is not currently in a state that that could be done. = For)263 2046 MS (example, it would not be appropriate for Note 3.1 to appear in IS 1539-1= =2E)263 2094 MS (Also, the section contains rules and explanatory material that doesn't)2= 63 2141 MS (necessarily belong in a new section 16. For example, in 3.3.4, the firs= t)263 2188 MS (paragraph after Note 3.15 states "The POINTER is n= ot)263 2235 MS (allowed because there is not C type whose corresponding Fortran type has= the)263 2283 MS (POINTER attribute." This more properly belongs in the edits to section = 4.4.1)263 2330 MS (of IS 1539-1 as a constraint. Another example is the definition of the = BIND)263 2377 MS (statement in 3.2 rather than adding it as an edit to section 4 of IS 153= 9-1.)263 2424 MS (Comment 26.)263 2519 MS n 257 2 263 2522 B f (General comment)263 2566 MS (Let's get a little philosophical. How can a vendor know if they conform= to)263 2613 MS (this TR and whose "fault" is it when a mixed language program fails? Th= e)263 2661 MS (intent seems to be one of giving Fortran programmers access to the opera= ting)263 2708 MS (system, graphics libraries, C language libraries, etc. However, there's= no)263 2755 MS (guarantee that these routines are written in C! They could easily be wr= itten)263 2802 MS (in assembly. It's not uncommon for parts of the Standard C Library to b= e)263 2850 MS (written in assembly. The C standard doesn't require that they actually = be written in C.)263 2897 MS (Consider this scenario:)263 2991 MS showpage %%Page: 6 6 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 6 of 20)1978 293 MS ( Vendor A provides a "standard conforming" C compiler for architecture = X)263 393 MS ( Vendor B provides a "standard conforming" Fortran compiler for archite= cture X)263 440 MS ( A mixed-language program fails)263 487 MS (Now, is it the Fortran vendor's "fault" if the C compiler is validated? = That is, the C function works)263 582 MS (fine when called from C so it must be the Fortran compiler's problem.)26= 3 629 MS (This seems like dangerous logic to get into. The best that can be done = here may be to make this an)263 723 MS (informative annex because there's no way to seriously check conformance = or to arbitrate resolution)263 771 MS (when mixed language programs fail. Unless the Fortran committee wants t= o say if the function)263 818 MS (works when called from C then it must be a Fortran problem.)263 865 MS (Now, if it can be the C compiler's fault then we recommend communication= be made with WG14/J11)263 960 MS (to make sure the C committee agrees with the responsibility that has jus= t placed upon their)263 1007 MS (shoulders.)263 1054 MS (Since the document chooses not to address mixed language I/O, every Fort= ran programmer wishing)263 1149 MS (to call a C function cannot put a "printf" or "fprintf" statement into t= heir C function as a means of)263 1196 MS (debugging their code. It is quite common in C to use "fprintf\(stderr, = =2E....\)" to issue diagnostics when)263 1243 MS (a function has been called incorrectly. It sounds like any function a u= ser might want to call from)263 1290 MS (Fortran had better not do that sort of thing. The same is true with the = "assert" macro. This seems)263 1338 MS (to me to be a serious limitation for any mixed language program, especia= lly if you want to call an)263 1385 MS (existing library routine.)263 1432 MS (Exactly what routines are I/O routines? Is it some or all of the routin= es defined in the standard)263 1527 MS (header ? For example, calling the "tmpnam" function seems tota= lly innocuous. What)263 1574 MS (about "sprintf" which is defined in but doesn't really do any = output to a file? What about)263 1621 MS (the "assert" macro? How about the "system" function? If an X-Windows r= outine pops up a window)263 1668 MS (on the screen and asks the user to enter their name, is that considered = to be I/O?)263 1716 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Bold MF (Category 2)263 1811 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (Comment 27.)263 1906 MS n 257 2 263 1909 B f (3.1, Note 3.2)263 1953 MS (The note says that not all entities contained in are required= to be)263 2000 MS (supported in ISO_C_STDDEF_H. Who chooses what is supported and what is = not?)263 2047 MS (Is this implementation-dependent?)263 2095 MS (Comment 28.)263 2189 MS n 257 2 263 2192 B f (3.1, Paragraphs following Note 3.2)263 2236 MS (Should this document mandate the names of these modules without any)263 = 2284 MS (specification of the contents? It's potentially confusing.)263 2331 MS (Comment 29.)263 2425 MS n 257 2 263 2428 B f (3.2, R1601)263 2473 MS (Why are the LANG=3D and NAME=3D specifiers specified as being optional b= ut PRAGMA=3D)263 2520 MS (is required for each specified pragma?)263 2567 MS (Comment 30.)263 2662 MS n 257 2 263 2665 B f (3.2, first constraint after R1604)263 2709 MS (Does the value of include leading or trailing blanks? We = assume)263 2756 MS (so, but we would like this clarified since blanks are ignored in determi= ning)263 2803 MS (the value of an I/O specifier.)263 2851 MS (Comment 31.)263 2945 MS n 257 2 263 2948 B f (3.3, Note 3.8)263 2992 MS (It states that "enum" types are not integer types \(but rather integral = types\).)263 3040 MS showpage %%Page: 7 7 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 7 of 20)1978 293 MS (Defect Report #067 asks the question about which category enumerated typ= es)263 393 MS (falls into. The reply starts out by saying:)263 440 MS ( "Signed integer type", "unsigned integer type", and plain)263 534 MS ( "integer type" are used interchangeably with "signed integral type",)= 263 582 MS ( "unsigned integral type" and "integral type" in the C Standard.)263 6= 29 MS (So, an enumerated type must map onto one of the integer types, but the)2= 63 723 MS (implementation need not reveal what the underlying type really is. I do= n't)263 771 MS (think you want to provide a binding to enum types in the TR, but Note 3.= 8)263 818 MS (should be corrected. The problem is that there is no way to tell what t= he)263 865 MS (underlying integral type really is.)263 912 MS (Comment 32.)263 1007 MS n 257 2 263 1010 B f (3.3.1, the list of C basic types and Fortran intrinsic types)263 1054 MS= (The names of the named constants should be spelled out so that the names= )263 1101 MS (have the same spellings as the C data types. For example, C_SHRT should= )263 1149 MS (be C_SHORT. We understand that Note 3.9 has the rationale for choosing)= 263 1196 MS (the names, but Fortran programmers are not going to be looking in these)= 263 1243 MS (headers. They are going to be somewhat familiar with the C data types)2= 63 1290 MS (so the terms used to describe these C data types should use the same wor= ds.)263 1338 MS (Comment 33.)263 1432 MS n 257 2 263 1435 B f (3.3.1, Note 3.10)263 1479 MS (It states that the type "char" is not an integer type. This is an incor= rect)263 1527 MS (assertion for the same reason as cited for "enum" above.)263 1574 MS (Comment 34.)263 1668 MS n 257 2 263 1671 B f (3.3.1, Note 3.12)263 1716 MS (The TR should not give suggestions about possible extensions.)263 1763 M= S (Comment 35.)263 1857 MS n 257 2 263 1860 B f (3.3.2, third paragraph)263 1905 MS (This indicates that the values made accessible shall conform to the)263 = 1952 MS (requirements of the C standard. What if that requires representation of= )263 1999 MS (values that are not model numbers in the Fortran model, e.g. -2**31?)26= 3 2046 MS (Comment 36.)263 2141 MS n 257 2 263 2144 B f (3.3.3)263 2188 MS (Perhaps we could provide partial support for enum types with integer kin= d)263 2235 MS (parameters named C_SCHAR_ENUM \(for enums whose value is within the sign= ed char)263 2283 MS (range\), C_SHORT_ENUM \(for those whose value is within the short int ra= nge\),)263 2330 MS (etc. This may help in almost all cases, but does not necessarily solve = the)263 2377 MS (problem, since the C processor may not use straightforward rules in dete= rmining)263 2424 MS (the representation for the enum type. Or perhaps a)263 2472 MS (SELECTED_ENUM_KIND\(LOW_ENUM, HIGH_ENUM\).)263 2519 MS (Of course, if the suggestion that enums not be supported is taken, this)= 263 2613 MS (comment can be ignored.)263 2661 MS (Comment 37.)263 2755 MS n 257 2 263 2758 B f (3.3.4, paragraph following Note 3.15)263 2802 MS (The first sentence should be a constraint.)263 2850 MS (Comment 38.)263 2944 MS n 257 2 263 2947 B f (3.3.6, Last paragraph)263 2991 MS (Change "may build on any" to "may build on either". On the other hand, = what)263 3039 MS showpage %%Page: 8 8 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 8 of 20)1978 293 MS (does it mean for the Fortran binding to "build on" the C type? How can)= 263 393 MS (Fortran "build on" double *?)263 440 MS (Should this paragraph be made into a note?)263 534 MS (Comment 39.)263 629 MS n 257 2 263 632 B f (3.3.6)263 676 MS (Should mismatched array shapes be prohibited? It's going to be easy for= the)263 723 MS (programmer to get confused between row-major and column-major subtleties= =2E)263 771 MS (Comment 40.)263 865 MS n 257 2 263 868 B f (3.3.7, second paragraph)263 912 MS (In which module is C_NULL defined? Also, where are the C_ISNULL, C_ADDR= ESS,)263 960 MS (et al. functions defined?)263 1007 MS (Comment 41.)263 1101 MS n 257 2 263 1104 B f (3.3.7, Description of C_ISNULL)263 1149 MS (Change "Compares PTR to zero")263 1196 MS (to "Compares PTR to the appropriate C null pointer".)263 1243 MS (\(or something like that\).)263 1290 MS (Should this function be elemental rather than transformational? Is the)= 263 1385 MS (function even necessary - why not provide operator\(=3D=3D\) and operato= r\(/=3D\))263 1432 MS (instead?)263 1479 MS (Comment 42.)263 1574 MS n 257 2 263 1577 B f (3.3.7, C_ADDRESS, C_DEREFERENCE, C_INCREMENT)263 1621 MS (Some of the arguments are permitted to be of any type. These should pro= bably)263 1668 MS (be restricted to be of types that are permitted in references to C proce= dures.)263 1716 MS (In addition, should zero-sized objects be prohibited from appearing?)263= 1810 MS (Comment 43.)263 1905 MS n 257 2 263 1908 B f (3.3.7, C_ADDRESS)263 1952 MS (Why is the result value undefined if OBJ is of one of the pointer types = and)263 1999 MS (C_ISNULL\(OBJ\) is true? Shouldn't this procedure be returning a pointe= r to)263 2046 MS (OBJ rather than a pointer to the objects OBJ points to?)263 2094 MS (Comment 44.)263 2188 MS n 257 2 263 2191 B f (3.3.7, C_DEREFERENCE - Result value Case \(i\))263 2235 MS (Change "*\(\(MOLD_T *\) PTR\) where PTR is ... PTR.")263 2283 MS (to "*\(\(MOLD_T *\) PTR\), where PTR is ... PTR, and MOLD_T is the t= ype of)263 2330 MS ( MOLD.")263 2377 MS (Comment 45.)263 2472 MS n 257 2 263 2475 B f (3.3.7, C_DEREFERENCE - Result value Case \(ii\))263 2519 MS (The description of the MOLD argument indicates that the MOLD argument sh= all be)263 2566 MS (present if PTR is of type TYPE\(C_STRUCT_PTR\), but Case \(ii\) indicate= s that the)263 2613 MS (result has the value of *\(PTR\), rather than expressing it as *\(\(MOLD= _T *\)PTR\).)263 2661 MS (Shouldn't cases \(ii\) and \(iii\) be combined?)263 2708 MS (Comment 46.)263 2802 MS n 257 2 263 2805 B f (3.3.7, C_DEREFERENCE - Result and Example Case \(iii\))263 2850 MS (Change "ASCII NUL" to "NUL" \(or whatever term is used to describe '\\0'= in the C standard - we)263 2897 MS (don't want to require support for ASCII.\) The PDTR should say somethin= g about '\\0' being the)263 2944 MS (same as CHAR \(0, KIND=3DC_CHAR\).)263 2991 MS showpage %%Page: 9 9 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 9 of 20)1978 293 MS (Comment 47.)263 393 MS n 257 2 263 396 B f (3.3.7, C_DEREFERENCE - Result value Case \(iii\))263 440 MS (The dependence on the string being NUL-terminated seems unfriendly. The= re's)263 487 MS (no requirement that char * point to a C string. Perhaps it should retur= n the)263 534 MS (value of \(char *\) \('h' in this case\), making it more consistent with= the other)263 582 MS (two cases. A separate set of procedures could be defined to handle the = string)263 629 MS (case.)263 676 MS (Comment 48.)263 771 MS n 257 2 263 774 B f (3.3.7, C_INCREMENT - Result value)263 818 MS (Change "\(PTR *\)\(\(MOLD *\)PTR+N\) where PTR is . . . PTR.")263 865 MS= (to "\(PTR *\)\(\(MOLD_T *\)PTR+N\), where PTR is . . . PTR,)263 912 = MS ( and MOLD_T is the type of MOLD.")263 960 MS (Comment 49.)263 1054 MS n 257 2 263 1057 B f (3.3.8)263 1101 MS (This section seems to imply that a C definition like:)263 1149 MS ( int func\(int n, float x\);)263 1243 MS ( int func\(n, x\))263 1338 MS ( int n; float x;)263 1385 MS ( { return n + x; })263 1432 MS (is not allowed because the definition uses old-style \(even though a pro= totype)263 1527 MS (is in scope\). Is this intended? Seems like this should say that the)2= 63 1574 MS ("type of the definition includes a function parameter list" and not focu= s on)263 1621 MS (the declarator.)263 1668 MS (Comment 50.)263 1763 MS n 257 2 263 1766 B f (3.3.9, R1606)263 1810 MS (The meaning of the on the needs to be)26= 3 1857 MS (specified. Compare to p.40, lines 39-41 of 1539-1.)263 1905 MS (Comment 51.)263 1999 MS n 257 2 263 2002 B f (3.3.9, first paragraph after constraints after R1606)263 2046 MS (Rule R502 of IS 1539-1 needs to be extended to permit TYPE\(\))263 2094 MS (as a .)263 2141 MS (Comment 52.)263 2235 MS n 257 2 263 2238 B f (3.3.10)263 2283 MS (If we're not specifying the meaning of volatile at all, we shouldn't per= mit)263 2330 MS (a Fortran entity to be associated with such an object.)263 2377 MS (Comment 53.)263 2472 MS n 257 2 263 2475 B f (3.3.10, last paragraph)263 2519 MS (Instead of specifying that if a C object of a const-qualified type is us= ed)263 2566 MS (in a way that violates the C standard, the object becomes undefined, sho= uldn't)263 2613 MS (we specify that such an object is not permitted to become redefined?)263= 2661 MS (Comment 54.)263 2755 MS n 257 2 263 2758 B f (3.3.11)263 2802 MS (Why is there a restriction on "register" being present for parameter)263= 2850 MS (declarations? Some rationale is needed.)263 2897 MS (Comment 55.)263 2991 MS n 257 2 263 2994 B f (3.4.2, Argument)263 3039 MS showpage %%Page: 10 10 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 10 of 20)1955 293 MS (As with the arguments to C_ADDRESS, et al., should the type be restricte= d?)263 393 MS (Should the TYPE argument be required to be of a type that has the BIND\(= C\))263 440 MS (attribute or of an intrinsic type that has a kind parameter defined in)2= 63 487 MS (the ISO_C module?)263 534 MS (After "it shall be allocated." add "It shall not be an assumed-size arra= y.".)263 629 MS (Comment 56.)263 723 MS n 257 2 263 726 B f (3.4.2, the Example)263 771 MS (The example uses the kind type parameter C_CHAR to precede a character)2= 63 818 MS (constant. Is there any implication here that C_CHAR implies the charact= er)263 865 MS (constant is terminated by the null character? The Argument description = for)263 912 MS (C_SIZEOF states that EXPR may be of any type. Does this mean that a def= ault)263 960 MS (character constant can be passed to it or is there some unstated expecta= tion)263 1007 MS (that it must be of type C_CHAR?)263 1054 MS (Comment 57.)263 1149 MS n 257 2 263 1152 B f (3.4.3)263 1196 MS (Why are all the new intrinsic functions prefixed by "C_" except for OFFS= ETOF?)263 1243 MS (This seems to be quite inconsistent.)263 1290 MS (Comment 58.)263 1385 MS n 257 2 263 1388 B f (3.4.3, Description)263 1432 MS (What does "its structure" mean? For example, in a structure reference)2= 63 1479 MS (of the form OUTER%MIDDLE%COMP is "its structure" defined to mean O= UTER)263 1527 MS (or OUTER%MIDDLE? Seems like it should be OUTER%MIDDLE since COMP is a)2= 63 1574 MS (component of OUTER%MIDDLE, but we can easily imagine that a user might w= ant to)263 1621 MS (know the offset of COMP within OUTER or within OUTER%MIDDLE. Does the)2= 63 1668 MS (specification of the TYPE argument \(which really should be STRUCTURE be= cause)263 1716 MS (we're talking about the offset within the object named with a structure = name,)263 1763 MS (not with a derived type name\) allow)263 1810 MS ( C_OFFSETOF\(OUTER, OUTER%MIDDLE%COMP\))263 1857 MS (as well as)263 1905 MS ( C_OFFSETOF\(OUTER%MIDDLE, OUTER%MIDDLE%COMP\))263 1952 MS (If there is no intent of allowing the second case then the first argumen= t is)263 2046 MS (superfluous.)263 2094 MS (Comment 59.)263 2188 MS n 257 2 263 2191 B f (3.5, first paragraph)263 2235 MS (This states that an explicit interface is required for a procedure defin= ed by)263 2283 MS (means of C, and that it have the BIND\(C\) attribute. Currently 1539-1 = doesn't)263 2330 MS (require this, so this requirement would cause conforming Fortran 95 prog= rams)263 2377 MS (to be non-conforming with respect to this TR.)263 2424 MS (Comment 60.)263 2519 MS n 257 2 263 2522 B f (3.5.1.2, Note 3.34)263 2566 MS (If the second sentence is "implying" a rule, the sentence should be move= d)263 2613 MS (out of the note and turned into a rule in normative text.)263 2661 MS (Comment 61.)263 2755 MS n 257 2 263 2758 B f (3.5.1.2, second bullet)263 2802 MS (Delete second bullet. It is confusing in a list of supported items and = how)263 2850 MS (they are supported. Also, delete sentence that reads "All other C point= er)263 2897 MS (types are not supported." Instead, insert before 1st paragraph of 3.5.1= =2E2,)263 2944 MS (something like:)263 2991 MS showpage %%Page: 11 11 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 11 of 20)1955 293 MS ( "The return type of the C function shall be void, a basic type,)263 39= 3 MS ( a structure type, pointer to void, pointer to struct or pointer)263 4= 40 MS ( to char. The return type is not permitted to be an enumeration)263 4= 87 MS ( type, a union type or any other C pointer type.")263 534 MS (Comment 62.)263 629 MS n 257 2 263 632 B f (3.5.1.3, R1607)263 676 MS (As in the BIND attribute, why is "PRAGMA=3D" required?)263 723 MS (Comment 63.)263 818 MS n 257 2 263 821 B f (3.5.1.3, the constraint for R1607)263 865 MS (Why force a user to write a zero-length string? If it doesn't apply the= n just)263 912 MS (don't specify it.)263 960 MS (Comment 64.)263 1054 MS n 257 2 263 1057 B f (3.5.1.3, Constraint after R1608)263 1101 MS (Why not permit blanks that are not significant as is done with I/O speci= fiers?)263 1149 MS (Comment 65.)263 1243 MS n 257 2 263 1246 B f (3.5.1.3, second paragraph after R1608)263 1290 MS (Change "A "*" character in the ")263 1338 MS (to "If the value of the is "*", it")263 1385 MS (\(Of course, the suggested modification will be affected by the followin= g)263 1432 MS (comment.\))263 1479 MS (Should some more suggestive value for the be used other= than)263 1574 MS ('*' and ''?)263 1621 MS (Reword the sentence that reads)263 1716 MS ( "A "*" character in the. . . "pointer to T"")263 1763 MS (As written, it implies that "pointer to T" is a Fortran type, whereas th= ere)263 1810 MS (are no pointer types in Fortran.)263 1857 MS (Comment 66.)263 1952 MS n 257 2 263 1955 B f (3.5.1.4, second bullet of first bulleted list and fifth bullet of the se= cond)263 1999 MS ( bulleted list)263 2046 MS (Reword in a way that is consistent with the suggestion for 3.5.1.2, seco= nd)263 2094 MS (bullet.)263 2141 MS (Comment 67.)263 2235 MS n 257 2 263 2238 B f (3.5.1.4)263 2283 MS (It is unclear how arrays are passed to C. Specifically, C is row major = and)263 2330 MS (Fortran is column major, but the TR states that the Fortran interface "s= hall)263 2377 MS (declare the type corresponding to the C type T, a DIMENSION attribute)26= 3 2424 MS (corresponding to the C array declarator, ...".)263 2472 MS (If the C parameter is declared:)263 2566 MS ( int A[2][3])263 2613 MS (then 3.3.6 states that the corresponding Fortran declaration is:)263 266= 1 MS ( INTEGER, DIMENSION\(3,2\) :: A)263 2708 MS (but what happens if the \(for all practical purposes\) identical declara= tions of:)263 2755 MS ( int \(*A\)[3])263 2802 MS (or)263 2850 MS ( int A[][3])263 2897 MS (are used? Should the corresponding Fortran declaration be:)263 2944 MS ( INTEGER, DIMENSION\(3,*\) :: A)263 2991 MS (It is not clear from the TR whether this is correct.)263 3039 MS showpage %%Page: 12 12 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 12 of 20)1955 293 MS (Comment 68.)263 393 MS n 257 2 263 396 B f (3.5.1.5, 4th bullet)263 440 MS (Change "A dummy argument or function result" to "A dummy argument".)263 = 487 MS (Comment 69.)263 582 MS n 257 2 263 585 B f (3.5.2.1)263 629 MS (Change "If the dummy argument")263 676 MS (to "If a dummy argument of a procedure with the BIND\(C\) attribute"= )263 723 MS (in the first sentence of each paragraph.)263 771 MS (Comment 70.)263 865 MS n 257 2 263 868 B f (3.5.2.1, second sentence \(beginning "It shall be"\))263 912 MS (What does "It" refer to? The dummy argument or actual argument? Same c= omment)263 960 MS (for second sentence of second paragraph following Note 3.40 and for the = second)263 1007 MS (sentence of the paragraph following Note 3.42. This same sentence follo= wing)263 1054 MS (Note 3.42 contains the phrase of type TYPE\(C_VOID_PTR\) which compares = equal)263 1101 MS (to NULL. Can it be compared equal to NULL or must it be passed to C_ISN= ULL?)263 1149 MS (Does the font indicate the C NULL? If so, why? Why not specify that it= must)263 1196 MS (be equal to the Fortran NULL constant?)263 1243 MS (The same question applies to )263 1338 MS NTPSOct95 /FontSV save put %%BeginFont: WP_TypographicSymbols042 10 dict dup begin /FontType 3 def /FontMatrix [1 42 div 0 0 1 42 div 0 0] def /FontBBox [0 -34 50 16] def /Encoding 256 array def 0 1 255 {Encoding exch /.notdef put} for /BuildGlyph {0 begin exch /CD get exch get /CI exch def CI 0 get 0 CI 1 4 getinterval aload pop setcachedevice CI 5 get CI 6 get true [1 0 0 -1 0 0] dup 4 CI 7 get put dup 5 CI 8 get put CI 9 get imagemask end}def /BuildGlyph load 0 5 dict put /BuildChar {1 index /Encoding get exch get 1 index /BuildGlyph get exec} bind def /CD 256 dict def CD /.notdef[.24 0 0 0 0 1 1 0 0 {<>}]put Encoding 65 /c65 put CD /c65 [15 2 28 13 17 11 11 -2 28 {<104030C06080E180C100C100F1E0F1E0F1E0F1E0F1E0>}]put end /WP_TypographicSymbols042 exch definefont pop %%EndFont [41.992 0 0 -41.992 0 0]/WP_TypographicSymbols042 MF (A)837 1338 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (It)852 1338 MS %%BeginFont: WP_TypographicSymbols042 /WP_TypographicSymbols042 findfont begin Encoding 64 /c64 put CD /c64 [15 3 28 14 17 11 11 -3 28 {}]put end %%EndFont [41.992 0 0 -41.992 0 0]/WP_TypographicSymbols042 MF (@)885 1338 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF ( in the second sentence of paragraph 3.)900 1338 MS (Comment 71.)263 1432 MS n 257 2 263 1435 B f (3.5.2.1, 3rd paragraph)263 1479 MS (The sentence that begins "ASSIGNMENT\(=3D\) for the types. . . " seems t= o describe)263 1527 MS (something that is unnatural. The entire concept that conversions for ac= tual)263 1574 MS (arguments happen implicitly on procedure references is foreign to Fortra= n, but)263 1621 MS (support for implicit defined assignment even when the defined assignment= is)263 1668 MS (not accessible is very strange. In addition, what happens when the user= )263 1716 MS (redefines assignment for these types?)263 1763 MS (Comment 72.)263 1857 MS n 257 2 263 1860 B f (3.5.2.2)263 1905 MS (Change "If a dummy argument")263 1952 MS (to "If a dummy argument of a procedure with the BIND\(C\) attribute"= )263 1999 MS (in the first sentence of each paragraph.)263 2046 MS (Comment 73.)263 2141 MS n 257 2 263 2144 B f (3.5.3)263 2188 MS (The handling of seems clumsy. Why is the operator specified = as)263 2235 MS ("OPERATOR\(//\)" instead of just "//"? This form is used for interface = blocks)263 2283 MS (and makes one think that an interface block for the operator // must be)= 263 2330 MS (provided somewhere. A suggested alternative would be to define a descri= ptive)263 2377 MS (procedure in ISO_C_STDARG_H that has a variable number of arguments \(si= milar)263 2424 MS (to MAX and MIN\). For example,)263 2472 MS ( call sub\(va_list\(i,j,k,a\(17\)\)\))263 2566 MS ( call sub\(va_list\(i,r\)\))263 2613 MS (If the first item in the list must always be VA_EMPTY, why make the user= write)263 2708 MS (it? The compiler can just construct the VA list this way.)263 2755 MS (Comment 74.)263 2850 MS n 257 2 263 2853 B f (3.5.3)263 2897 MS (Since VA_LIST must be a derived type, it seems like the corresponding C = type)263 2944 MS (must be a structure type. Many implementations of va_list use a pointer= )263 2991 MS (instead. This could be a problem if, say, the minimum size for any deri= ved)263 3039 MS showpage %%Page: 13 13 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 13 of 20)1955 293 MS (type is 64-bits but a pointer is 32-bits.)263 393 MS (Comment 75.)263 487 MS n 257 2 263 490 B f (3.6)263 534 MS (It should be noted when such a variable becomes defined \(as is done in = 14.7.5)263 582 MS (of 1539-1 for variables which are initialized\).)263 629 MS (Comment 76.)263 723 MS n 257 2 263 726 B f (3.6, first bullet after Note 3.51)263 771 MS (Change "No initialization shall appear in the .")263 818 MS= (to "initialization shall not appear in an in a)263 865= MS ( for a variable with the BIND\(C\) attrib= ute.")263 912 MS (Comment 77.)263 1007 MS n 257 2 263 1010 B f (3.6, second bullet after Note 3.51)263 1054 MS (Change "ALLOCATABLE, PARAMETER or POINTER shall not be specified.")263 1= 101 MS (to "The variable shall not)263 1149 MS ( * have the ALLOCATABLE, PARAMETER or the POINTER attribute)263= 1196 MS ( * be an automatic object)263 1243 MS ( * be a function result variable.")263 1290 MS (Comment 78.)263 1385 MS n 257 2 263 1388 B f (3.6, last paragraph before Note 3.52)263 1432 MS (Change "If two or more. . . are accessible in a scoping un= it")263 1479 MS (to "If two or more. . . ")263 1527 MS (Comment 79.)263 1621 MS n 257 2 263 1624 B f (3.6, last paragraph)263 1668 MS (It's not clear what this paragraph is saying. Is it talking about thing= s like)263 1716 MS (errno? Also, what does it mean to say that "The Fortran processor is no= t)263 1763 MS (required to guard such behavior"?)263 1810 MS (Comment 80.)263 1905 MS n 257 2 263 1908 B f (3.7, paragraph preceding Note 3.54)263 1952 MS (The last sentence is describing a comparison to \(apparently\) the C NUL= L again)263 1999 MS (instead of using the Fortran NULL or C_ISNULL.)263 2046 MS (Comment 81.)263 2141 MS n 257 2 263 2144 B f (4, 2nd constraint in edits for page 38)263 2188 MS (Change "the same " to "the same ".)263 2235 M= S (\(At least, we think that was what was intended.\))263 2283 MS (Comment 82.)263 2377 MS n 257 2 263 2380 B f (4, edits for page 38)263 2424 MS (Is BIND\(FORTRAN\) permitted to appear in a derived type definition? If= so,)263 2472 MS (what effect does it have? Should the SEQUENCE statement still be prohib= ited)263 2519 MS (for that case?)263 2566 MS (Comment 83.)263 2661 MS n 257 2 263 2664 B f (General comment)263 2708 MS (C9X is due to hit the streets in 1999. So, by the time this TR makes)26= 3 2755 MS (it into a Fortran standard, there will be a new \(and hopefully improved= \))263 2802 MS (C Standard. The TR should attempt to align itself with C9X.)263 2850 MS= (Things to consider:)263 2944 MS ( new keywords: restrict, complex)263 3039 MS showpage %%Page: 14 14 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 14 of 20)1955 293 MS ( new headers: )263 393 MS ( is likely to be added soon)263 440 MS ( external names: 31 characters, mixed case)263 487 MS ( new types: long long, unsigned long long, float complex,)263 534 MS ( double complex, long double complex,)263 582 MS ( restricted pointers, variable length arrays)263 629 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Bold MF (Category 3)263 724 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (Comment 84.)263 819 MS n 257 2 263 822 B f (1.4, item 1)263 866 MS (Change "Mixed-Language Input and Output" to "Mixed-language input and ou= tput".)263 913 MS (Comment 85.)263 1008 MS n 257 2 263 1011 B f (1.4, item 4)263 1055 MS (Change "and some pointer types" to ", some pointer types, and bit fields= ".)263 1102 MS (Comment 86.)263 1197 MS n 257 2 263 1200 B f (1.5)263 1244 MS (Delete "first-class" \(twice\) {we don't use this kind of terminology i= n the)263 1291 MS (standard})263 1339 MS (Comment 87.)263 1433 MS n 257 2 263 1436 B f (2, first paragraph)263 1480 MS (What is meant by "the standard \(de-facto or de-jure\) computing environ= ment?)263 1528 MS (What standard? A Macintosh in someone's home does not generally have a = C)263 1575 MS (compiler on it and yet it seems to be a productive computing environment= =2E)263 1622 MS (Comment 88.)263 1717 MS n 257 2 263 1720 B f (2, second paragraph after bulleted list)263 1764 MS (Change "environment: Many" to "environment - many".)263 1811 MS (Also in this paragraph in the sentence beginning "Due to the difficultie= s...":)263 1906 MS (People are not moving to C because of the difficulties of producing a st= andard)263 1953 MS (for communications between Fortran and C; they are moving to C because t= here)263 2000 MS (is no such standard at all or because it is more "natural" to write the)= 263 2047 MS (application in C.)263 2095 MS (Comment 89.)263 2189 MS n 257 2 263 2192 B f (3, Note 3.1)263 2236 MS (Given the general statement on section 3 \(in category 1\), this note sh= ould be)263 2284 MS (deleted.)263 2331 MS (Comment 90.)263 2425 MS n 257 2 263 2428 B f (3.1, the bulleted list)263 2473 MS (Who is going to provide these standard modules and by what mechanism are= they)263 2520 MS (going to be kept current with the C standard?)263 2567 MS (Comment 91.)263 2662 MS n 257 2 263 2665 B f (3.1, second bullet in list)263 2709 MS (Is "common definitions" a C term? If not, a different term should be us= ed to)263 2756 MS (avoid confusion with the Fortran meaning of the word "common".)263 2803 = MS (Comment 92.)263 2898 MS n 257 2 263 2901 B f (3.1, First paragraph after Note 3.2)263 2945 MS (Change "facilites" to "facilities".)263 2992 MS showpage %%Page: 15 15 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 15 of 20)1955 293 MS (Comment 93.)263 393 MS n 257 2 263 396 B f (3.1, 1st paragraph after Note 3.3)263 440 MS ("name" appears in italics once, but other occurrences are not italicized= =2E)263 487 MS (Comment 94.)263 582 MS n 257 2 263 585 B f (3.2, the first paragraph and throughout the remainder of the document)26= 3 629 MS (Each section reference should be qualified so the reader knows what docu= ment)263 676 MS (the section number is relative to. For example, in the first paragraph = of)263 723 MS (3.2, section 1.4 could refer to this document or to the Fortran 95 stand= ard.)263 771 MS (Comment 95.)263 865 MS n 257 2 263 868 B f (3.2, paragraph following the constraints following R1604)263 912 MS (Change ", this" to ". This".)263 960 MS (Comment 96.)263 1054 MS n 257 2 263 1057 B f (3.2, 1st paragraph after Note 3.6)263 1101 MS (Change "which" to "that".)263 1149 MS (Comment 97.)263 1243 MS n 257 2 263 1246 B f (3.2, Constraint after R1605)263 1290 MS (Change "which" to "that".)263 1338 MS (Comment 98.)263 1432 MS n 257 2 263 1435 B f (3.3, Note 3.7)263 1479 MS (Change "are supported, see" to "are supported; see".)263 1527 MS (Comment 99.)263 1621 MS n 257 2 263 1624 B f (3.3, paragraph following Note 3.7)263 1668 MS (Change "define object types" to "define data types".)263 1716 MS (Comment 100.)263 1810 MS n 280 2 263 1813 B f (3.3, Paragraph after Note 3.8)263 1857 MS (Change "Fortran types, access" to "Fortran types; access".)263 1905 MS (Change "C datatypes: Derived" to "C data types. Derived".)263 1952 MS (Change "recursively applied," to "recursively applied, and".)263 1999 MS= (Comment 101.)263 2094 MS n 280 2 263 2097 B f (3.3.1, first paragraph)263 2141 MS (Change "and real types: The intrinsic" to "and real types. The intrins= ic".)263 2188 MS (Comment 102.)263 2283 MS n 280 2 263 2286 B f (3.3.1, the list of C basic types and Fortran intrinsic types)263 2330 MS= (The names of the kind parameters should be listed before specifying whic= h)263 2377 MS (data types correspond to which C data types.)263 2424 MS (Comment 103.)263 2519 MS n 280 2 263 2522 B f (3.3.1, Note 3.11)263 2566 MS (It's not clear whether this note is suggesting things that an implementa= tion)263 2613 MS (needs to do to support the unsigned types or something the user needs to= do.)263 2661 MS (Comment 104.)263 2755 MS n 280 2 263 2758 B f (3.3.3, before Note 3.13)263 2802 MS (Change "implementation-defined: It" to "implementation-defined. It".)2= 63 2850 MS (Comment 105.)263 2944 MS n 280 2 263 2947 B f (3.3.4, Last sentence of paragraph after Note 3.14)263 2991 MS (Replace with)263 3039 MS showpage %%Page: 16 16 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 16 of 20)1955 293 MS ( "A shall not be specified for any)263 393 = MS ( component of a derived type that has the BIND\(C\) attribute.")263 4= 40 MS (Comment 106.)263 534 MS n 280 2 263 537 B f (3.3.4, Note 3.15)263 582 MS (Change "the Fortran member objects" to "the Fortran derived type compone= nts".)263 629 MS (Change "way: The" to "way. The".)263 723 MS (Comment 107.)263 818 MS n 280 2 263 821 B f (3.3.4, second paragraph following Note 3.15)263 865 MS (This is the first time TYPE\(C_STRUCT_PTR\) has been seen. This may con= fuse)263 912 MS (the reader, and cause them to search back toward the front of the docume= nt to)263 960 MS (locate the definition of this term. It turns out that this term is defi= ned)263 1007 MS (later in the document. The term should either be defined before this)26= 3 1054 MS (reference or there should be a forward reference here to where this term= is)263 1101 MS (defined.)263 1149 MS (Comment 108.)263 1243 MS n 280 2 263 1246 B f (3.3.4, Note 3.16)263 1290 MS (Same point as above for TYPE\(C_CHAR_PTR\) in the example.)263 1338 MS (Comment 109.)263 1432 MS n 280 2 263 1435 B f (3.3.4, Paragraph after Note 3.16)263 1479 MS (Delete the sentence that begins "In either case, ...". It's not clear w= hy the)263 1527 MS (user might have thought that the length information would be stored in t= he)263 1574 MS (structure.)263 1621 MS (Comment 110.)263 1716 MS n 280 2 263 1719 B f (3.3.5, Note 3.18)263 1763 MS (Change "union members: In" to "union members. In".)263 1810 MS (Or just delete the note entirely. We shouldn't give suggestions as to h= ow to)263 1905 MS (write non-conforming code.)263 1952 MS (Comment 111.)263 2046 MS n 280 2 263 2049 B f (3.3.6, Note 3.21)263 2094 MS (Change "the transposition must be done by the user")263 2141 MS (to "one can use the RESHAPE intrinsic with the ORDER argument presen= t".)263 2188 MS (Comment 112.)263 2283 MS n 280 2 263 2286 B f (3.3.7, C_ISNULL, C_ADDRESS, et al.)263 2330 MS (Each of these functions should probably be in a separate little section = \(as)263 2377 MS (is done for the Fortran intrinsic procedures\).)263 2424 MS (Comment 113.)263 2519 MS n 280 2 263 2522 B f (3.3.7, second paragraph)263 2566 MS (Change "are supported: The" to "are supported. The".)263 2613 MS (Comment 114.)263 2708 MS n 280 2 263 2711 B f (3.3.7, paragraph preceding "C_ISNULL\(PTR\)")263 2755 MS (Change "All C pointers" to "In a C program, all pointers". In the next)= 263 2802 MS (sentence, insert "in Fortran" following "this comparison".)263 2850 MS (Comment 115.)263 2944 MS n 280 2 263 2947 B f (3.3.7, Result value description and Example for C_ISNULL)263 2991 MS (The Fortran standard uses "true" and "false" for logical values in the)2= 63 3039 MS showpage %%Page: 17 17 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 17 of 20)1955 293 MS (descriptions of intrinsic procedures rather than ".TRUE." and ".FALSE.".= )263 393 MS (Comment 116.)263 487 MS n 280 2 263 490 B f (3.3.7, Note 3.22)263 534 MS (It's not clear what the first sentence of this note is trying to say.)26= 3 582 MS (Shouldn't it be sufficient to say that none of the operators is defined)= 263 629 MS (on these types. \(We don't think it's really necessary to say even that= )263 676 MS ( much.\))263 723 MS (Comment 117.)263 818 MS n 280 2 263 821 B f (3.3.7, C_DEREFERENCE - Example Case \(iii\))263 865 MS (Change "character string of length 5" to "character string of length 6".= )263 912 MS (\(Is the length returned by LEN or strlen that is being discussed?\))263= 960 MS (Comment 118.)263 1054 MS n 280 2 263 1057 B f (3.3.7, Note 3.27, paragraph following the extern example)263 1101 MS (The first sentence of the note should remain. The remainder of the note= )263 1149 MS (should be replaced with an example that would be valid. There is no gua= rantee)263 1196 MS (that the representation of void * will be the same as the representation= of)263 1243 MS (char **. If this functionality is actually required, a C_CHAR_PTR_PTR t= ype)263 1290 MS (should be defined.)263 1338 MS (Comment 119.)263 1432 MS n 280 2 263 1435 B f (3.3.7, Last paragraph)263 1479 MS (This last paragraph should be made informative.)263 1527 MS (Comment 120.)263 1621 MS n 280 2 263 1624 B f (3.3.9, first constraint after R1606)263 1668 MS (Change "1539" to "1539-1". \(There are other instances as well.\))263 1= 716 MS (Comment 121.)263 1810 MS n 280 2 263 1813 B f (3.3.9, first paragraph after constraints after R1606)263 1857 MS (Change "interchangeable" to "interchangeably".)263 1905 MS (Change "corresponding : entities" to "corresponding .)263 1952 MS (Entities".)263 1999 MS (Comment 122.)263 2094 MS n 280 2 263 2097 B f (3.3.9, Note 3.29)263 2141 MS (Change "hidded" to "hidden".)263 2188 MS (Comment 123.)263 2283 MS n 280 2 263 2286 B f (3.3.10, last paragraph)263 2330 MS (We think the sentence about a Fortran processor not being required to di= agnose)263 2377 MS (violations that take place while a C subprogram is executing can be dele= ted.)263 2424 MS (Comment 124.)263 2519 MS n 280 2 263 2522 B f (3.3.11, Note 3.30)263 2566 MS (Delete "\(which is comparable to Fortran PRIVATE entities\)".)263 2613 M= S (Comment 125.)263 2708 MS n 280 2 263 2711 B f (3.4.1, Note 3.31)263 2755 MS (Why does this note exist? The result types of C_SIZEOF and OFFSETOF are= )263 2802 MS (explicitly described in the descriptions of these two new intrinsic func= tions.)263 2850 MS (Comment 126.)263 2944 MS n 280 2 263 2947 B f (3.4.3)263 2991 MS (Delete the comma in the section title.)263 3039 MS showpage %%Page: 18 18 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 18 of 20)1955 293 MS (Comment 127.)263 393 MS n 280 2 263 396 B f (3.4.3, 2nd paragraph)263 440 MS (Change "follwing" to "following".)263 487 MS (Comment 128.)263 582 MS n 280 2 263 585 B f (3.4.3, Description)263 629 MS (Change "strucure" to "structure".)263 676 MS (Change both the second argument and the word "member" in the first sente= nce to)263 771 MS (the word "component". The Fortran standard uses "component", not "membe= r".)263 818 MS (In Result Characteristics, "imlementation-defined" is misspelled)263 912= MS (\(missing the "p"\).)263 960 MS (Since the next section of the description does not capitalize the word)2= 63 1054 MS ("value", "Characteristics" should also not be capitalized. \(This same)= 263 1101 MS (capitalization change should be made in other intrinsic descriptions)263= 1149 MS (elsewhere in the document as well.\))263 1196 MS (In Result value, delete the comma after "C standard\)".)263 1290 MS (Comment 129.)263 1385 MS n 280 2 263 1388 B f (3.5.1, first paragraph)263 1432 MS (Change "inluding" to "including".)263 1479 MS (Comment 130.)263 1574 MS n 280 2 263 1577 B f (3.5.1, Note 3.33)263 1621 MS (Change "parantheses" to "parentheses".)263 1668 MS (Or just delete this note. It describes how a user might do something th= at is)263 1763 MS (expressly prohibited by the normative text preceding the note.)263 1810 = MS (Comment 131.)263 1905 MS n 280 2 263 1908 B f (3.5.1.1, first sentence)263 1952 MS (Italicize "".)263 1999 MS (Comment 132.)263 2094 MS n 280 2 263 2097 B f (3.5.1.2, 1st paragraph after Note 3.34)263 2141 MS (Delete "The declaration of the function result variable shall be as foll= ows:")263 2188 MS (Comment 133.)263 2283 MS n 280 2 263 2286 B f (3.5.1.3, Constraint after R1608)263 2330 MS (Remove quotes around asterisk - they are not part of the value.)263 2377= MS (Comment 134.)263 2472 MS n 280 2 263 2475 B f (3.5.1.3, first paragraph after R1608)263 2519 MS (Change " this" to ". This".)263 2566 MS= (Comment 135.)263 2661 MS n 280 2 263 2664 B f (3.5.1.4, second paragraph)263 2708 MS (Delete "The Fortran declaration. . . as follows:".)263 2755 MS (Comment 136.)263 2850 MS n 280 2 263 2853 B f (3.5.1.4, sentence following Note 3.37)263 2897 MS (Change "of the C function" to "of a C function" and change "type: If" t= o)263 2944 MS ("type. If".)263 2991 MS showpage %%Page: 19 19 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 19 of 20)1955 293 MS (Comment 137.)263 393 MS n 280 2 263 396 B f (3.5.1.4, 6th bullet of second bulleted list)263 440 MS (Change "funtion" to "function".)263 487 MS (Comment 138.)263 582 MS n 280 2 263 585 B f (3.5.1.4, last paragraph)263 629 MS (Change "All other C pointer types are not supported.")263 676 MS (to "No other C pointer types are permitted.")263 723 MS (Comment 139.)263 818 MS n 280 2 263 821 B f (3.5.1.5, 8th bullet)263 865 MS (Change "shall have an explicit interface, and that interface")263 912 MS= (to "shall have explicit interfaces, and those interfaces")263 960 MS= (Comment 140.)263 1054 MS n 280 2 263 1057 B f (3.5.2.1, last sentence before Note 3.43)263 1101 MS (Rather than indicating that the actual argument has to obey the same set= of)263 1149 MS (restrictions that something else obeys, repeat the restrictions for this= case.)263 1196 MS (Comment 141.)263 1290 MS n 280 2 263 1293 B f (3.5.2.1, Paragraph 3, last sentence.)263 1338 MS (Change )263 1385 MS [41.992 0 0 -41.992 0 0]/WP_TypographicSymbols042 MF (A)424 1385 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (is)439 1385 MS [41.992 0 0 -41.992 0 0]/WP_TypographicSymbols042 MF (@)471 1385 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF ( to )486 1385 MS [41.992 0 0 -41.992 0 0]/WP_TypographicSymbols042 MF (A)547 1385 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (are)562 1385 MS [41.992 0 0 -41.992 0 0]/WP_TypographicSymbols042 MF (@)625 1385 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (.)640 1385 MS (Comment 142.)263 1479 MS n 280 2 263 1482 B f (3.5.2.3)263 1527 MS (Delete this note and section. It should not be necessary to call the us= er's)263 1574 MS (attention to this.)263 1621 MS (Comment 143.)263 1716 MS n 280 2 263 1719 B f (3.5.2.3)263 1763 MS (The first occurrence of the word "free" need not be in bold Courier sinc= e)263 1810 MS (it is not referring to the free\(\) function.)263 1857 MS (Comment 144.)263 1952 MS n 280 2 263 1955 B f (3.5.2.3)263 1999 MS (The phrase "to take care about" seems awkward.)263 2046 MS (Comment 145.)263 2141 MS n 280 2 263 2144 B f (3.5.3, first paragraph)263 2188 MS (Change "procedure interfaces." to "procedure interface.".)263 2235 MS (Comment 146.)263 2330 MS n 280 2 263 2333 B f (3.5.3, Note 3.45)263 2377 MS (Delete this note. Each of Fortran and C is able to do things that the o= ther)263 2424 MS (cannot.)263 2472 MS (Comment 147.)263 2566 MS n 280 2 263 2569 B f (3.5.3, the bullet at the top of page 35)263 2613 MS (Change "to operands x1 of type" to "to operands x1 and x2 of type".)263 = 2661 MS (In the last sentence of this bullet, change "x2," to "x2;".)26= 3 2755 MS (Comment 148.)263 2850 MS n 280 2 263 2853 B f (3.6, first sentence after Note 3.51)263 2897 MS (Change "additonal" to "additional".)263 2944 MS (Comment 149.)263 3039 MS n 280 2 263 3042 B f showpage %%Page: 20 20 9 776 translate 72 300 div dup neg scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itran= sform translate [63 0 0 -63 0 0]/NewCenturySchlbk-Bold MF (J3 / 97-223r1)1812 147 MS [41.996 0 0 -41.996 0 0]/NewCenturySchlbk-Roman MF (NCITS/J3 ANSI Fortran Standards Committee)263 198 MS (Interoperability Subgroup)1705 198 MS (Interoperability with C - Response to PDTR)263 245 MS (August 12, 1997)1899 245 MS (Page 20 of 20)1955 293 MS (3.6, third bullet after Note 3.51)263 393 MS (Is it necessary to mention that CHARACTER with assumed character length = is not)263 440 MS (permitted? This should follow from the fact that it is not permitted to= be)263 487 MS (a dummy argument or named constant.)263 534 MS (Comment 150.)263 629 MS n 280 2 263 632 B f (3.6, last paragraph before Note 3.52)263 676 MS (Change "They all refer to the same storage.")263 723 MS (to "All such variables are storage associated.")263 771 MS (Comment 151.)263 865 MS n 280 2 263 868 B f (3.6, paragraph after Note 3.52)263 912 MS (Is this paragraph necessary? Shouldn't this follow from the definition = of)263 960 MS (storage association? Perhaps it should be made into a note if it's felt= to)263 1007 MS (be necessary.)263 1054 MS (Comment 152.)263 1149 MS n 280 2 263 1152 B f (3.7, paragraph preceding Note 3.54)263 1196 MS (Change "an MOLD" to "a MOLD".)263 1243 MS (Comment 153.)263 1338 MS n 280 2 263 1341 B f (3.7, Note 3.54)263 1385 MS (Change "allows to load X resources from command line arguments" to)263 1= 432 MS ("allows X resources to be loaded from command line arguments".)263 1479 = MS (Comment 154.)263 1574 MS n 280 2 263 1577 B f (4, edit for page xvi)263 1621 MS (Change "defined by Fortran code" to "defined by a Fortran module program= unit".)263 1668 MS (Comment 155.)263 1763 MS n 280 2 263 1766 B f (4, edits for page 48)263 1810 MS (Change "may only" \(two occurrences\) to "shall only".)263 1857 MS (Change "which" to "that".)263 1905 MS (Comment 156.)263 1999 MS n 280 2 263 2002 B f (4, Annex D)263 2046 MS (In most instances cross-references are left unqualified, so it is someti= mes)263 2141 MS (unclear whether the reference is to a section within the PDTR, a section= in)263 2188 MS (the Fortran DIS or a section in the ISO C standard.)263 2235 MS showpage FontSV restore PageSV restore %%Trailer %%DocumentNeededFonts: %%+ Courier %%+ NewCenturySchlbk-Bold %%+ NewCenturySchlbk-Roman %%DocumentSuppliedFonts: %%+ WP_TypographicSymbols042 end %%Pages: 20 %%EOF