From rinehuls@access.digex.net Mon Sep 22 18:02:11 1997 Received: from access4.digex.net (qlrhmEbBUV1EY@access4.digex.net [205.197.245.195]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id SAA18848 for ; Mon, 22 Sep 1997 18:01:58 +0200 Received: from localhost (rinehuls@localhost) by access4.digex.net (8.8.4/8.8.4) with SMTP id MAA26873; Mon, 22 Sep 1997 12:01:40 -0400 (EDT) Date: Mon, 22 Sep 1997 12:01:39 -0400 (EDT) From: "william c. rinehuls" X-Sender: rinehuls@access4.digex.net Reply-To: "william c. rinehuls" To: miles ellis , sc22docs@dkuug.dk Subject: SC22 N2589 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII __________________ beginning of title page ___________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2589 TITLE: Summary of Voting on Concurrent PDTR Registration and PDTR Approval for PDTR 15815 - Information technology - Programming languages, their environments and system software interfaces - Interoperability of Fortran and C DATE ASSIGNED: 1997-09-18 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Summary of Voting PROJECT NUMBER: JTC 1.22.02.01.03 STATUS: PDTR 15815 has been registered. WG5 is requested to prepare a Disposition of Comments Report and a recommendation on the further processing of the PDTR. ACTION IDENTIFIER: FYI to SC22 Member Bodies ACT to WG5 DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: SC22 N2468 DISTRIBUTION FORM: Def Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ________________ end of title page; beginning of summary ____________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N2468 Circulated by: JTC 1/SC22 Circulation Date: 05-28-1997 Closing Date: 09-11-1997 SUBJECT: Concurrent PDTR Registration and PDTR Approval for PDTR 15815 - Information technology - Programming languages, their environments and system software interfaces - Interoperability of Fortran and C The following responses have been received on the subject of PDTR registration: "P" Members supporting registration without comments: 14 "P" Members supporting registration with comments: 0 "P" Members not supporting registration: 2 "P" Members abstaining: 2 "P" Members not voting: 5 The following responses have been received on the subject of PDTR approval: "P" Members supporting approval without comments: 12 "P" Members supporting approval with comments: 2 "P" Members not supporting approval: 2 "P" Members abstaining: 2 "P" Members not voting: 5 Secretariat Action: PDTR 15815 has been registered. WG5 is requested to prepare a Disposition of Comments Report and a recommendation on the further processing of the PDTR. _______ end of overall summary; beginning of detailed registration summary ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY Registration Ballot PROJECT NO: JTC 1.22.02.01.03 SUBJECT: Concurrent PDTR Registration and PDTR Approval for PDTR 15815 -Information technology - Programming languages, their environments and system software interfaces - Interoperability of Fortran and C Reference Document No: N2468 Ballot Document No: N2468 Circulation Date: 05-28-1997 Closing Date: 09-11-1997 Circulated To: SC22 P, O, L Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Australia (X) ( ) ( ) ( ) ( ) Austria ( ) ( ) (X) ( ) ( ) Belgium (X) ( ) ( ) ( ) ( ) Brazil ( ) ( ) ( ) ( ) (X) Canada ( ) ( ) (X) ( ) ( ) China (X) ( ) ( ) ( ) ( ) Czech Republic ( ) ( ) ( ) ( ) (X) Denmark (X) ( ) ( ) ( ) ( ) Egypt (X) ( ) ( ) ( ) ( ) Finland (X) ( ) ( ) ( ) ( ) France (X) ( ) ( ) ( ) ( ) Germany (X) ( ) ( ) ( ) ( ) Ireland ( ) ( ) ( ) ( ) (X) Japan (X) ( ) ( ) ( ) ( ) Netherlands (X) ( ) ( ) ( ) ( ) Norway (X) ( ) ( ) ( ) ( ) Romania (X) ( ) ( ) ( ) ( ) Russian Federation (X) ( ) ( ) ( ) ( ) Slovenia ( ) ( ) ( ) ( ) (X) Sweden ( ) ( ) ( ) ( ) (X) UK ( ) (X) ( ) (X) ( ) Ukraine (X) ( ) ( ) ( ) ( ) USA ( ) (X) ( ) (X) ( ) 'O' Members Argentina ( ) ( ) ( ) ( ) ( ) Bulgaria ( ) ( ) ( ) ( ) ( ) Cuba ( ) ( ) ( ) ( ) ( ) Greece ( ) ( ) ( ) ( ) ( ) Hungary ( ) ( ) ( ) ( ) ( ) Iceland ( ) ( ) ( ) ( ) ( ) India ( ) ( ) ( ) ( ) ( ) Indonesia ( ) ( ) ( ) ( ) ( ) Italy ( ) ( ) ( ) ( ) ( ) Korea Republic ( ) ( ) ( ) ( ) ( ) New Zealand ( ) ( ) ( ) ( ) ( ) Poland ( ) ( ) ( ) ( ) ( ) Portugal ( ) ( ) ( ) ( ) ( ) Singapore ( ) ( ) ( ) ( ) ( ) Thailand ( ) ( ) ( ) ( ) ( ) Turkey ( ) ( ) ( ) ( ) ( ) Yugoslavia ( ) ( ) ( ) ( ) ( ) _________ end of registration summary; beginning of approval summary ____ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY Approval Ballot PROJECT NO: JTC 1.22.02.01.03 SUBJECT: Concurrent PDTR Registration and PDTR Approval for PDTR 15815 - Information technology - Programming languages, their environments and system software interfaces - Interoperability of Fortran and C Reference Document No: N2468 Ballot Document No: N2468 Circulation Date: 05-28-1997 Closing Date: 09-11-1997 Circulated To: SC22 P, O, L Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Australia (X) ( ) ( ) ( ) ( ) Austria ( ) ( ) (X) ( ) ( ) Belgium (X) ( ) ( ) ( ) ( ) Brazil ( ) ( ) ( ) ( ) (X) Canada ( ) ( ) (X) ( ) ( ) China (X) ( ) ( ) ( ) ( ) Czech Republic ( ) ( ) ( ) ( ) (X) Denmark (X) ( ) ( ) ( ) ( ) Egypt (X) ( ) ( ) ( ) ( ) Finland (X) ( ) ( ) ( ) ( ) France (X) ( ) ( ) (X) ( ) Germany (X) ( ) ( ) (X) ( ) Ireland ( ) ( ) ( ) ( ) (X) Japan (X) ( ) ( ) ( ) ( ) Netherlands (X) ( ) ( ) ( ) ( ) Norway (X) ( ) ( ) ( ) ( ) Romania (X) ( ) ( ) ( ) ( ) Russian Federation (X) ( ) ( ) ( ) ( ) Slovenia ( ) ( ) ( ) ( ) (X) Sweden ( ) ( ) ( ) ( ) (X) UK ( ) (X) ( ) (X) ( ) Ukraine (X) ( ) ( ) ( ) ( ) USA ( ) (X) ( ) (X) ( ) 'O' Members Argentina ( ) ( ) ( ) ( ) ( ) Bulgaria ( ) ( ) ( ) ( ) ( ) Cuba ( ) ( ) ( ) ( ) ( ) Greece ( ) ( ) ( ) ( ) ( ) Hungary ( ) ( ) ( ) ( ) ( ) Iceland ( ) ( ) ( ) ( ) ( ) India ( ) ( ) ( ) ( ) ( ) Indonesia ( ) ( ) ( ) ( ) ( ) Italy ( ) ( ) ( ) ( ) ( ) Korea Republic ( ) ( ) ( ) ( ) ( ) New Zealand ( ) ( ) ( ) ( ) ( ) Poland ( ) ( ) ( ) ( ) ( ) Portugal ( ) ( ) ( ) ( ) ( ) Singapore ( ) ( ) ( ) ( ) ( ) Thailand ( ) ( ) ( ) ( ) ( ) Turkey ( ) ( ) ( ) ( ) ( ) Yugoslavia ( ) ( ) ( ) ( ) ( ) _______________ end of approval summary; beginning of comments accompanying France approval vote ____ From: ARNAUD.A.R.D.DIQUELOU@email.afnor.fr Thank you for recording the following French vote on: _N2468 - PDTR 15815 Interoperability of Fortran and C, and concurrent letter ballots on PDTR registration and PDTR approval ---1--- The registration of doc. N2468 as PDTR : YES ---2--- The approval of doc. N1277 or PDTR 15815 ''Interoperability of Fortran and C'' : YES WITH COMMENTS (see below) --------------------------------------------------------------------- Technical comments : ____________________ 1) Page 21, about result value of function C_DEREFERENCE, case (ii) : We think that the sentence is in error (the argument MOLD is not used) or incomplete. 2) Some examples will be welcome, especially in : Note 3.27 (page 23) or par. 3.5.1.4 (page 29) 3) Page 37, par. 3.6, Note 3.52 : we are not aware of ''that Fortran prohibits the appearrance of a module variable as the variable-name in a common-block-object or as an equivalence-object ....''. It seems to us that it is possible in the module that defines such variables, BUT not in any module that uses this module. Sorry, we don't understand what the author has in his mind ! 4) What about the binding with the second part of IS:1539-2 (variable length character string in Fortran) ?? Editorial Comments : ____________________ A) Page 1, paragraph 1.1, line 3 : As decided (really ?) for the name of the first part of the Fortran standard 1539-1 replace ''current Fortran language'' by ''current base Fortran language'' Page 3, paragraph 1.7, line 11 : the same. B) Page 19, about result value of function C_ADDRESS, at the end : Better wording (?), as written page 21 for the result value of function C_DEREFERENCE : If C_ISNULL(OBJ) is true (or .TRUE. ??), the result is (also) undefined. Page 22, about result value of function C_INCREMENT : the same. Page 19, 21 and 22 : What is the best ? : If C_ISNULL(...) is true OR If C_ISNULL(...) is .TRUE. C) Page 31, line 5 : replace ''a type "function returning T1"'' by ''a type "function returning T"'' D) Page 34, Note 3.46, line 5 : replace ''callee'' by ''caller'' E) References to the base Fortran standard are not very clearly stated. For instance, ref. (1.4) page 7, par. 3.2, line 2 ; ref. (12.5.3) page 7, par. 3.2, line 4 ; ref. (6.2.2.2) page 17, par. 3.3.6, line 25 ; ref. (13.14.111), page 17, par. 3.3.6, line 30 refer to the IS 1539-1 and not to the present document. ____ end of French comments; beginning of Germany comments accompanying affirmative vote ____________________________________________ German voting on PDTR 15815, ISO/IEC JTC1/SC22/N2468, Interoperability of Fortran and C YES, Germany supports the proposal that document ISO/IEC JTC1/SC22/N2468 (same as ISO/IEC JTC1/SC22/WG5/N1277), or its revised version, be registered as PDTR 15815. YES, Germany approves the draft PDTR 15815 with the following comments: 1. General comments 1.1 Although mixing C and Fortran input and output is intentionally not addressed by the TR, it is unclear if a C procedure might perform I/O at all. Shouldn't the TR say something about the question who is responssible for bringing up the C runtime environment? Or should this problem be solved outside the standard? 1.2 The conformance clauses of the TR need to be more precise, especially concerning conformance of the processor. 1.3 Depending on the schedule of C9X and this TR, several C9X additions may be included in the TR. The new standard headers ISO_C_COMPLEX_H ISO_C_FENV_H ISO_C_INTTYPES_H ISO_C_BOOL_H (not sure yet) may be added to section 3.1 of the PDTR. The new basic datatypes long long INTEGER(C_LONG_LONG) float complex COMPLEX(C_FLT) double complex COMPLEX(C_DBL) long double complex COMPLEX(C_LDBL) may be added to section 3.3.1 of the PDTR (if C's and Fortran's complex types may differ in memory layout, the latter three might require derived types rather than binding to COMPLEX). 2. Technical comments 2.1 Document WG5/N1265, part 2, requested that arguments to C_ADDRESS shall have the TARGET attribute. This should be added to the PDTR. 2.2 In accordance with WG5/N1265 part 3, the text in WG5/N1237 to restrict C pointer operations (esp. C_ADDRESS and C_DEREFERENCE) to objects of C types has been removed from the PDTR. Germany recommends that these restrictions be reinstated. 2.3 The type aliasing mechanism is ambiguous. It should be enhanced along the lines of WG5/N1298. 2.4 Germany proposes that the C pointer support be enhanced by adding at least the following derived types to the ISO_C module: TYPE(C_SCHAR_PTR) TYPE(C_SHRT_PTR) TYPE(C_INT_PTR) TYPE(C_LONG_PTR) TYPE(C_FLT_PTR) TYPE(C_DBL_PTR) TYPE(C_LDBL_PTR) to support pointers to the basic types (one pointer indirection), and TYPE(C_CHAR_PTR_PTR) to support char** in addition to the existing support for char*. All of these types shall have BIND(C) attribute and PRIVATE components. 2.5 With these new derived types, arguments and result types of the procedures for C pointer support need to be revised. Strong type checking should be enforced for dereferencing a pointer to a C basic type. 2.6 ARGV in 3.7 should be changed to type TYPE(C_CHAR_PTR_PTR) and the text of this section should be revised accordingly. 2.7 Text needs to be added to specify the behavior in cases where the for a C basic type is negative but a C_DEREFERENCE of a C pointer type derived from it is attempted. 2.8 A TYPE(C_FNC_PTR) to support C function pointers may be added. Dummy procedures in an interface to a C procedure may then be declared either with an interface block having the BIND(C) attribute or with this new derived type. This parallels the F2000 requirement for Fortran procedure pointers/variables, which will probably include both an implicit (EXTERNAL) and an explicit (INTERFACE) version of procedure pointers. 2.9 Germany recommends to delete support for unsigned integer types from the PDTR (too limited in scope, not sufficiently important). The constants C_UCHAR, C_USHRT, C_UINT and C_ULONG should be deleted, and the first paragraph on page 11 should be removed or changed to an informative note. 2.10 Support for enumerated types should be added, as outlined in WG5/N1299. 2.11 The PDTR prohibits the use of arrays which are potentially not dense in memory (assumed-shape dummy arguments, pointer arrays, etc) as actual arguments to C procedures. These restrictions should be deleted. Rationale: The restrictions are present to avoid potential problems with COPYIN/COPYOUT argument association semantics. However, they are unnecessary in all cases where access to the argument is not asynchronous. The behavior when calling C functions with array arguments should be similar to that when calling Fortran procedures with assumed size array arguments -- which may involve compiler-generated temporaries. The asynchroneous problem may occur in both cases, it should not be addressed by the PDTR but rather by the ongoing work for F2000 asynchronous I/O and the ASYNC attribute. 2.12 Binding to C data that is qualified "volatile" should be prohibited. 2.13 The necessity for the restriction in 3.3.11 concerning register storage class specifiers on C function parameters should be checked. 2.14 It has been pointed out that the numerical bounds of the C environment are macros, not constants. This means that in section 3.3.2 the term "constant" should probably be avoided. 3. Editorial comments whole document: qualify all references to sections in IS 1539-1 and IS 9899, delete all qualifications of references to sections within the PDTR, and add text to section 1.6 explainig this. Possibly incomplete list: page 7: (1.4) - IS 1539-1 page 7: (12.5.3) - IS 1539-1 page 11: (12.5.7) - IS 1539-1 page 12: (13.5.7) - IS 1539-1 page 12: (6.2.2) - IS 1539-1 page 12: (13.14.11) - IS 1539-1 page 24: IS 1539 in 2nd constraint - IS 1539-1 page 28: (6.5.4.3) - IS 9899 page 28: 3.3 - TR page 29: 3.3 - TR page 32: IS 539 in note 3.29 - IS 1539-1 page 32: (6.5.2.2) - IS 9899 (twice) page 36: 3.3 - TR (on next page) whole document: change mnemonic names of constants to names which contain the C type names rather than the mnemos according to note 3.9, and delete note 3.9 page 3, note 1.3: delete note page 4, bulleted list: add MPI (message passing interface) to the list page 10, note 3.8: delete note [there is an C interp classifying enums as integer types] page 10, first line of 3.3.1: add (including enumerated types) after [see edit for note 3.8] page 27, section 3.5.1: notes with examples should be added to illustrate these facilities page 39, edit for page 7: delete reference to ANSI C standard ______ end of Germany comments; beginning of UK comments accompanying negative vote ____________________________________________________ UK vote in SC22 ballot on PTDR 15815 (SC22/N2468) on Interoperability of Fortran and C. PDTR Registration Ballot The UK votes 'no'. The initial (1995) objective of this Technical Report was to define a proposed standard method of enabling Fortran programs to access C procedures, to be published as quickly as possible and prior to completion of the revision of the Fortran base language standard which is scheduled for 2002. The task has proved far more difficult than was anticipated and has fallen behind schedule. The UK believes that the requirement is now best treated as an integral requirement for the revision of the base language standard, and not as a separable entity. There is thus no reason to proceed with the Technical Report. PDTR Content Ballot Should the vote be in favour of registering the PDTR, the UK votes 'no' on content. There are technical and editorial deficiencies which are detailed below. Major technical flaws: (1) C-style pointer arithmetic is imported into the Fortran language without sufficient safeguards to keep the existing language efficient and/or to make pointer arithmetic safe; in particular, the argument to the C_ADDRESS function must be required to have the TARGET attribute (cf WG5-N1261 LV4 and WG5-N1265 section 2). (2) There is no support for interfacing to C "enum" types. (3) There should be some distinction between by-reference arguments to C functions according to whether the C function stores somewhere a pointer to the argument; otherwise an actual argument passed by reference will be forever "tainted" by the possibility of it being a pointer target. All arrays, as well as "output" arguments, are passed by reference. Minor technical flaws: (4) There is some confusion in the document between C_NULL and NULL in various guises, and also between "zero" and the null pointer (in C). The null pointer in C is not "zero" and should not be referred to as such. (5) C_ISNULL appears to be redundant and unnecessary. (6) Type aliases are introduced, but are not used for providing the standard C types; instead, kind numbers are provided (C_CHAR et al) and applied to the Fortran intrinsic types. Type aliases should probably be used as the user cannot then make the mistake of using a kind number with the wrong type; this is most likely with the "char" types, which are: CHARACTER(C_CHAR), INTEGER(C_SCHAR), INTEGER(C_UCHAR). Editorial flaws: (7) Some text that must be normative is in (informative) notes. (8) MOLD is used both to designate a (dummy) variable name and, in the same paragraph, the type of that variable. (9) Naming is sometimes inconsistent; e.g. C_SIZEOF but OFFSETOF. Further comments: (A) The draft TR uses the example of "extern char **environ;" in order to justify importing almost the entirety of C pointer arithmetic (it does not import pointer differencing). This example is unconvincing - it does not need the full potentially damaging power of pointer arithmetic vented onto Fortran optimisers to access C's "pointer to variable-length array" entities - a simpler, safer, alternative could be devised. (B) The piecemeal approach of importing a subset of C facilities into Fortran (until sufficient facilities are imported to support interfacing to a selected subset of useful C libraries) has the undesirable effects of: (i) some C functions cannot be interfaced to, in particular - ones with enum arguments - ones with function arguments (actually, these can be interfaced to but only with actual arguments that are also C functions, not Fortran procedures). (ii) Fortran becomes more complicated, with all these extra datatypes that must be supported (not just in C interfaces); e.g. a compiler that does not at present support small INTEGER types (8-bit and 16-bit) would not be able to support calling C functions expecting those types without supporting them through the entire Fortran language. (C) MPI is a widely used de-facto standard which is in effect a C library. It may not be practicable to support all of MPI from Fortran, but there should be consideration of the interface between Fortran and MPI and ideally a discussion of what is and what is not supported, perhaps in an annex. _____ end of UK comments; beginning of USA comments accompanying negative vote __________________________________________________ The US National Body votes to Disapprove ISO/IEC PDTR 15815, Information Technology - Programming languages, their environments and system software interfaces - Interoperability of Fortran and C. Comments listed below: Category 1: is defined as technical flaws which must be repaired. Category 2: is defined as technical flaws which must be dealt with. Category 3: is defined as 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 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(==) an 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 th 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. ___________________________ end of SC22 N2589 ____________________________