From owner-sc22wg5@open-std.org Wed Mar 9 22:51:28 2011 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 63483C178E7; Wed, 9 Mar 2011 22:51:28 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1632 seconds by postgrey-1.18 at www2.open-std.org; Wed, 09 Mar 2011 22:51:25 CET Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by www2.open-std.org (Postfix) with ESMTP id C3DEEC178E4 for ; Wed, 9 Mar 2011 22:51:25 +0100 (CET) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p29LO9R1009547 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Wed, 9 Mar 2011 13:24:10 -0800 Subject: Re: (j3.2006) (SC22WG5.4409) WG informal ballot From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: "sc22wg5@open-std.org" In-Reply-To: <20110304095000.610DEC3BA01@www2.open-std.org> References: <20110304095000.610DEC3BA01@www2.open-std.org> Content-Type: text/plain Organization: Yes Date: Wed, 09 Mar 2011 13:24:05 -0800 Message-Id: <1299705849.2615.129.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Content-Transfer-Encoding: 7bit X-Source-IP: math.jpl.nasa.gov [137.79.7.57] X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Fri, 2011-03-04 at 01:39 -0800, John Reid wrote: > WG5, > > Bill has been pointed out that I made a mistake in the ballot paper that > I sent you yesterday. Please discard that one and use this one instead. ISO/IEC JTC1/SC22/WG5 N1846 WG5 letter ballot on N1845 John Reid, 3 March 2011 This is the letter ballot that WG5 agreed to hold on the draft PDTR for further interoperability of Fortran with C. This has been constructed by J3 following its recent meeting. Section 6 was constructed during the meeting and is incomplete. For example, it needs text in the style of the Standard for the functions of 5.2.5. I am hoping that a more complete version may become available soon, but I do not think it needs to be complete for the PDTR since it does not affect the technical content of the facility. Our schedule, see N1843, does not permit delaying this ballot. Please answer the following question "Is N1845 ready for forwarding to SC22 as the PDTR?" in one of these ways. 2) Yes, but I recommend the following changes: Mostly quibbles about wording, except for items 8 and 36, which request technical changes. 1. [Introduction, p5, line 2] Replace "require that any changes be made" by "require any changes to be made". 2. [1.1p1 1:8] Insert a comma after "C" 3. [2.1p3+ UTI TR17 3:16+] Yes. 4. [2.2p4+ UTI TR18 4:5+] Yes 5. [3.3p2 5:15-16] Should be a constraint. But... similar provisions in Clause 12 of 1539-1 are not constraints. 6. [4.1p1 7:3] Insert "subclause" before "4.2". 7. [5.2.1p1 9:9] It is not clear what base types CFI_attribute_t, CFI_index_t, CFI_rank_t and CFI_type_t have. They are simply described as "typedef". "typedef" for what? Integers, I suspect. The base type should be specified. 8. [5.2.1p3 9:19-21] Is there a good reason to prohibit a C source file from having any identifiers other than the ones gotten from ISO_Fortran_binding.h to begin with CFI_? A "google" search for "CFI" returned 6,320,000 results, so it is conceivable that a pre-existing C file might have identifiers beginning with CFI, and then someday need to be interoperable. For example, at http://www.gocfi.com we see "CFI provides Enterprise Asset Management, Computerized Maintenance Management System, Archibus, CMMS Software,...." If possible, delete this paragraph. 9. [5.2.2p1 9:23] CFI_cdesc_t is described as a "typedef" but it's not in the list of "typedef" names in 5.2.1p1. Is there a more precise C term that could be used here? I didn't know that a "typedef" had members. Is "typedef for a struct" correct? 10. [5.2.2p1 CFI_dim_t+ 10:12+] 5.2.3p3-4 concern the ordering of dimensions (5.2.3p3), or the properties of the array as a whole (5.2.3p4), not the properties of one dimension. Those paragraphs should therefore be in 5.2.2. 11. [5.2.3p1 10:14] CFI_dim_t is described as a "typedef" but it's not in the list of "typedef" names in 5.2.1p1. Is there a more precise C term that could be used here? I didn't know that a "typedef" had members. Is "typedef for a struct" correct? 12. [5.2.3p1 lower_bound 10:18] Replace "lower bound of an array for a specified dimension" by "lower Fortran bound for the dimension being described". "of an array" isn't needed because the introductory paragraph says CFI_dim_t is used to represent bounds of arrays. 13. [5.2.3p1 extent 10:19] Replace "of an array along a specified dimension" by "along the dimension being described". 14. [5.2.3p1 sm 10:21] Replace "of the array along a specified dimension" by "along the dimension being described". 15. [5.2.3p3 10:24-25] Replace "sm value" by "sm member" twice. Insert "the CFI_dim_t struct for" before "one dimension". The latter change is recommended because item 10 recommends to move this paragraph to 5.2.2. 16. [5.2.3p4 10:28-29] Replace "member attribute" by "attribute member"; replace "member extent" by "extent member"; replace "member dim" by "dim member". 17. [5.2.4p5 Table 5.1] Replace "assumed" by "assumed shape" (to distinguish from "assumed type" or "assumed rank"). Dehyphenate "assumed-size". 18. [5.2.5 13:1-17:26] Since C formal parameter names are written in lower case, it's not obvious from reading the text what is an argument name and what is an ordinary word. Either use "code font" for argument names, or the layout of the description of intrinsic functions that is used in Clause 13 of 1539-1 (or both). Constructions such as "argument dv" should be "dv argument" throughout 5.2.5. Otherwise one at first reads "argument result" or "argument attribute" or "argument type" to mean "the result of the argument" or "the attribute of the argument" or "the type of the argument". That is, "the argument type" reads too much like "the argument's type" at first glance. 19. [5.2.5.2 13:16-17] Provide a name, say "dv", for the CFI_cdesc_t formal parameter. After "C descriptor" insert "pointed to by the dv argument". 20. [5.2.5.2p1 13:19,21] Replace "subscripts array" by "subscripts argument" twice. 21. [5.2.5.3 13:22,24-14:1] Provide a name, say "dv", for the CFI_cdesc_t formal parameter. 21a [5.2.5.3p1 13:24-14:1] Replace "an object" by "the object described by the C descriptor pointed to by the dv argument". Replace "is not for" by "does not describe". 21b. [5.2.5.3p1 14:2,3] Replace "arrays" by "arguments" twice. 21c. [5.2.5.3p1 14:3] After "rank" insert "$r$". Before "lower_bounds" insert "first $r$ elements of the". 21d. [5.2.5.3p1 14:4] Before "bounds" insert "Fortran" twice. 21e. [5.2.5.3p1 14:8] Replace "is" by "might be" since the "is" assertion was denied twice already. 22. [5.2.5.4 14:9] Provide a name, say "dv", for the CFI_cdesc_t formal parameter. 22a. [5.2.5.4p1 14:10] Replace "an object that was" by "the object described by the C descriptor pointed to by the dv argument. It shall have been". 22b. [5.2.5.4p1 14:16] Replace "is" by "might be" since the "is" assertion was denied twice already. 23. [5.2.5.5p1 14:19] After "establishes" insert "the dv argument to be". 23b. [5.2.5.5p3 14:28-29] Before "a C descriptor" insert "the descriptor pointed to by the dv argument to be" twice. 24. [5.2.5.5p6 14:38] What are the units of the size of an element of the object? Bytes? Whatever is returned by the C sizeof operator? 24b. [5.2.5.5p6 14:39] What are the units of the length of an element of the character object? Bytes? Characters (which might be more than one byte each)? 25. [5.2.5.5p7 14:41] Replace second "dim" by "Fortran dimension". 26. [5.2.5.6 15:27] Provide a name, say "dv", for the CFI_cdesc_t formal parameter. 26a. [5.2.5.6p1 15:28] Insert "descriptor pointed to by the dv" before "argument". 27. [5.2.5.7p1 15:32] Replace "result" by "the result argument". 27a. [5.2.5.7p1 15:33] Replace "pointed to by source" by "described by the C descriptor pointed to by the source argument". 28. [5.2.5.7p3 15:38] Replace "and" by "; it" or ". It". 29. [5.2.5.7p5 15:42] Replace "dim information of" by "Fortran dimension information for". 30. [5.2.5.8p1 16:13] Replace "a C descriptor" by "the C descriptor pointed to by the result argument" (compare 5.2.5.7p1). 31. [5.2.5.8p1 16:13-14] This only works for one part at a time. Replace "whose elements are parts" by "for which each element is a part". Replace "The parts" by "The part". 32. [5.2.5.8p3 16:20] Replace "and" by "; it" or ". It". 33. [5.2.5.8p4 16:23] Replace "arguments displacement and elem_len" by "displacement and elem_len arguments". 34. [5.2.5.8p6 16:28] Replace "type" by "the type argument". 35. [5.2.5.9p3 17:7] Before \cf{ptr_dv} insert "the Fortran pointer described by the C descriptor pointed to by" 35a. [5.2.5.9p4 17:9] Replace "\cf{ptr_dv} C descriptor" by "C descriptor pointed to by \cf{ptr_dv}". 35b. [5.2.5.9p5 17:1] C doesn't use the term "target of". Replace "target of \cf{ptr_dv}" by "the C descriptor pointed to by \cf{ptr_dv}". 36. [5.2.8p3(2)(a) 18:28-29] Why did we go to the trouble to develop descriptors for array arguments, and then not allow (a pointer to) one as a function result? This should allow the result to have the Fortran POINTER or ALLOCATABLE attribute. The result would be a C pointer to a descriptor of type CFI_desc_t. The processor should be able to handle this with the same mechanisms it uses for arguments. This is an individual vote. Please send your vote to sc22wg5@open-std.org to arrive by 9 a.m. (UK time) on March 31st 2011. Comments from people outside WG5 will be very welcome.