J3/97-188r1 To: J3 From: /Interop (lrr) Subj: U.S. comments on Interoperability PDTR Ballot (III) Ref: J3/97-187 Date: 15 May 1997 * 1.5, first paragraph: delete "first-class" {we don't use this kind of terminology in the standard} * 1.5, paragraph following Note 1.1: same change * 1.7, Note 1.3: why are there two versions of the C standard mentioned? I don't understand how one term can mean the other. * 2, first paragraph: what is meant by "the standard (de-facto or de-jure) computing environment? What standard? My Mac at home does not even have a C compiler on it and it seems to be a very nice computing environment. * 2, second paragraph following the bullet list, 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 or because it is more "natural" to write the appication in C. * 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. * 3, Note 3.1: Given the above general statement on section 3, this note should be deleted. * 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? * 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? * 3.1, the paragraph following 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 portablility if vendors can not only choose which headers they support but can also determine the contents of the headers. * 3.2, the first paragraph and throughout the remainder of the document: should clarify each section reference 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. * 3.2, R1601: Why arethe LANG= and NAME= specifiers specified as being optional but PRAGMA= is required for each specified pragma. As in the Fortran 95 standard, they can appear in any order when the keywords are specified, right? * 3.2, paragraph following the constraints following R1604: (editorial) change "lang-keyword, this" to "lang-keyword. This". * 3.3, Note 3.7: (editorial) change "are supported, see" to "are supported; see". * 3.3, paragraph following Note 3.7: change "define object types" to "define data types". * 3.3, paragraph following Note 3.8: change "Fortran types, access" to "Fortran types; access". also change "C datatypes: Derived" to "C data types. Derived". * 3.3.1, first paragraph (editorial): change "and real types: The intrinsic" to "and real types. The intrinsic". * 3.3.1, the list of C basic types and Fortran intrinsic type: spell out the names of the named constants so that the names have the same spellings as the C data types. For example, C_SHRT should be C_SHORT. I 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. * 3.3.3, before Note 3.13 (editorial): change "implementation-defined: It" to "implementation- defined. It". * 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. * 3.3.4, paragraph following Note 3.15: The first sentence should be a constraint. * 3.3.4, second paragraph following Note 3.15: this is the first time TYPE(C_STRUCT_PTR) has been seen. This caused me great confusion and caused me to dig toward the front of the document to see where I had missed 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. * 3.3.4, Note 3.16: same point as above for TYPE(C_CHAR_PTR) in the example. * 3.3.5, Note 3.18 (editorial): change "union members: In" to "union members. In". * 3.3.7, second paragraph (editorial): change "are supported: The" to "are supported. The". * 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". * 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.". * 3.3.7, Note 3.24: This is also true of many more instances than just automatic objects. Why are automatic objects the only ones mentioned? * 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, doesn't a dereference of a character pointer only reference a single character? If this is true and if C_DEREFERENCE by definition always gets you 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? * 3.3.7, Note 3.27, paragraph following the extern example: "This type is not supported" should be clarified to state this type is not supported in Fortran (surely it is supported in C since you just described it). I also don't understand why the sentence says "if" the representations are the same. Does the C standard leave this up to the implementation? * 3.3.9, second constraint: can the type-alias-name be the same as a variable name? a common block name? a procedure name? the name of a named constant? How is this taken care of in the Chapter 14 name class description? * 3.3.9, paragraph following the second constraint: change "interchangeable" to "interchangeably" and change "corresponding type-spec: entities" to "corresponding type-spec. Entities". * 3.3.9, Note 3.29: delete the comma following "". * 3.3.9, Note 3.29 and the syntax description for the type-alias-stmt: The syntax for the type alias statement is ambiguous. One may name a pointer "TYPEXID" and one may have an array named "INTEGER" that has the TARGET attribute. Since fixed source form still exists in the language, even in the presence of the C_ISO module, TYPE XID => INTEGER(c_ulong) could easily be a pointer assignment statement. * 3.3.9, paragraph following Note 3.28: the second sentence states: If the aliased type-spec is an intrinsic type, a structure-constructor for type-alias-name shall contain a single expr, which shall be assignment compatible with that intrinsic type. Why would you want to invent the whole new idea that a structure constructor can be constructed for an intrinsic type? Why should the type-alias-name become a derived type if the type-spec 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). Creating a new name for an intrinsic type would be a generally useful feature. I don't understand why the type alias needs to be a derived type if the type spec is for an intrinsic type and I 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". I think a Fortran user would be very surprised that a type alias for an integer type is a derived type. * 3.3.10, last paragraph: I think you can delete the sentence about a Fortran processor not being required to diagnose violations that take place while a C subprogram is executing. * 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. * 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? * 3.4.3, Delete the comma in the section title. Why are all the new intrinsic functions prefixed by C_ except for OFFSETOF? This seems to be very inconsistent. * 3.4.3 If you are defining the NULL constant, why do you need C_ISNULL? 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? * 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". 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 MIDDLE? Seems like it should be MIDDLE since COMP is a component of MIDDLE but I can easily imagine that a user might want to know the offset of COMP within OUTER or within 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 you have no intent of allowing the second case then the first argument is superfluous. 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)". * 3.5.1.2, Note 3.34: If the second sentence is "implying" a rule, then the sentence should be moved out of the note and turned into a rule in normative text. * 3.5.1.2, second bullet: This doesn't make any sense in the context of this bulleted list. It should be pulled out of the list and made into a rule. * 3.5.1.3, R1607: As in the BIND attribute, why is PRAGMA= required? * 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. * 3.5.1.4, second bullet of first bulleted list and fifth bullet of the second bulleted list: Same comment as for 3.5.1.2. * 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". * 3.5.1.4, 6th bullet of second bulleted list: change "funtion" to "function" * 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 you compare it equal to NULL or must you pass it 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? * 3.5.2.3: Do you really want to have a section that consists of nothing but a note? The first occurrence of the word free need not be in bold Courier since it is not referring to the free() function. The phrase "to take care about" seems awkward. * 3.5.3, first paragraph, last word: should be singular. * 3.5.3, first bullet following Note 3.46: Why do you write "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. I don't like overloading the // operator in this manner. Another mechanism should be found that is more descriptive (like just using a keyword like VA_LIST: I = FUNC(FD, F_DUPFD, VA_LIST(first, second)) And 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. * 3.5.3, the bullet at the top of page 35: In the first sentence, do you really mean for "operands" to be plural? It seems to only reference x1. Did you mean to say "x1 and x2"? In the last sentence of this bullet, change "x2," to "x2;". * 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. Change "an MOLD" to "a MOLD". * 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".