To: J3 Members J3/16-142r1 From: Van Snyder & Bill Long Subject: Comments on Clause 15 Reference: 16-007 Date: 2016 February 08 1. Edits ======== Group A - Accepted changes -------------------------- [457:19 15.2.1p1] Replace "and" with a comma. After "C_FUNPTR" insert ", and the procedures in 15.2.3". {The procedures in 15.2.3 are a required part of the module.} [457:33 15.2.2p3] After "companion processor" insert "(2.5.7)". A cross reference to the definition of the term ought to appear at least once in Clause 15 -- the earlier the better. {The definition is at 1.3.33 [6:7-9]. However, the description at 2.5.7 is more useful.} [457:34 15.2.2p3] Replace "C processor" with "companion processor". {Parallel sentence structure: For "if X defines T, ... or if Y does not define T", change Y to X in the second case.} [460:47 15.2.3.3] Replace "when" with "where". {Temporal "when" not appropriate here.} [461:6 15.2.3.3] Replace "will associate" with "associates". Replace "specify" with "specifies". {Use active verbs.} [461:26,28 15.2.3.5p5] Replace "FPTR" with "CPTR twice. {The name can be anything. The choice of CPTR fits better with the C_F_PROCPOINTER description.} [464:0+17 NOTE 15.7] Replace "derived" by "defined" (typedef means "type definition," doesn't it?) {The word "derived" is used in C for types refers to pointers. Defined is better here.} [464:4+2,3 NOTE 15.9] Replace "the same" with "a single" twice. Using "the same" might lead one to believe that object pointers and function pointers necessarily have the same representation. {Improved wording.} [472:21 15.5.4p9] Replace "which" with "that". {Corrected wording.} [475:20-21 15.5.5.3p2] Append "if \cf{dv->rank} > 0" twice. {The bounds arrays are ignored is the rank is zero. The "shall be the address of an array" requirement is excessive in the case of rank = 0.} [476:36 15.5.5.5p2] Replace "will be" with "is". {Active verb.} [482:21+11,12,14 NOTE 15.33] Replace "will create" with "creates". Replace "will become" with "becomes" twice. {Active verbs} [484:9 15.10.1p3] Replace "called" with "invoked". {The C standard uses "invoked" and the Fortran standard uses that term.} [484:17 15.10.1p5] After "invoked as" insert ",or by,". {Edit modified from 16-142 to emphasize that we want to disallow an exception handler from calling a Fortran procedure.} [485:20 15.10.4p2] At the end of the penultimate sentence of paragraph 2 of 15.10.4 Asynchronous communication, change "transfer" to "transfer (5.5.4)". {Edit modified from 16-142. Instead of a separate Note, include a reference to the normative text with the content of the proposed note.} Group N - Changes not accepted ------------------------------ [457:14 15.1p3] Replace "an assumed length" with "assumed length or specified length greater than one". {See NOTE 15.25.} {Interoperability of character type is limited to "If the type is character, the length type parameter is interoperable if and only if its value is one." 15.3.2p1 [463:9-10]. Interoperability of interfaces requires either "the dummy argument is a nonallocatable nonpointer variable of type CHARACTER with assumed character length and the formal parameter is a pointer to CFI_cdesc_t, [467;18-19] 15.3.7p2 (5), or "each allocatable or pointer dummy argument of type CHARACTER has deferred character length" [467:24] 5.3.7p2 (6). In no case for an interoperable interface is a dummy argument of type character with specified length greater than one supported.} [461:27 15.2.3.5p5] The description invites the reader to imagine that CPTR has a pointer component. 15.3.3 says it does not. {15.3.3 is correct. This is why 15.2.3 says "as if". The purpose is to use Fortran-like syntax in the explanation.} [462:10 15.2.3.6[6] The description invites the reader to imagine that C_PTR has a pointer component. 15.3.3 says it does not. {15.3.3 is correct. This is why 15.2.3 says "as if". The purpose is to use Fortran-like syntax in the explanation.} [462:16 15.2.3.6p8] Replace "C processor" with "companion processor". {Makes no sense to talk about the unary & operator unless it is a C processor.} [463:9-10 15.3.2p1] Delete "If the type ... value is one." {This is the rule for type interoperability of character and needs to be stated.} [464:1- NOTE 15.8+] Insert a NOTE: "NOTE 15.8a If the type is character and the length is not specified by a constant expression having the value one, a descriptor (15.4) is used." {Unhelpful Note.} [464:4+2 NOTE 15.9] Replace "C processor" with "companion processor". {The explicit reference to the C standard makes "C processor" appropriate here.} [466:9 15.3.6p1] This says that an array is interoperable only if it is of explicit shape or assumed size. Didn't the TS provide for descriptors for assumed-shape and deferred-shape arrays? {The TS added interoperability of interfaces with dummy arguments that are assumed-shape and deferred-shape arrays. This is not the same as the data objects themselves being interoperable.} [469 NOTE 15.23:2, 6-8] After "simply contiguous" insert "(6.5.4)". Delete "A dummy ... or a pointer." This simply repeats the definition in 6.5.4. {Notes are intended to be helpful explanatory text. Including the text for simply contiguous here is helpful.} [474:17 15.5.5.2p2] Replace "Formal" with "Actual". It's clear from the descriptions, as in Clause 13, that it's requirements on the actual parameters (arguments in Clause 13) being described. {There is no "Actual Parameters" concept in C. It is either "Formal Parameter" (the dummy names) or "Actual Arguments" (which would not be the same as the dummy names, in general). Several other rejections for the same reason}. [475:15 15.5.5.3p2] Replace "Formal" with "Actual". {Same issue as [474:17] edit.} [476:4 15.5.5.4p2] Replace "Formal" with "Actual". {Same issue as [474:17] edit.} [476:23 15.5.5.5p2] Replace "Formal" with "Actual". {Same issue as [474:17] edit.} [477:11+6 NOTE 15.30] Replace "will produce" with "produces". {"will" seems better here since it is conditional} [478:4 15.5.5.6p2] Replace "Formal" with "Actual". {Same issue as [474:17] edit.} [478:12 15.5.5.7p2] Replace "Formal" with "Actual". {Same issue as [474:17] edit.} [478:14 15.5.5.7p2] Set "strides" in code font. {The "strides" in the code is an address/pointer. The zero values of interest are the ones pointed to by strides.} [479:34 15.5.5.8p2] Replace "Formal" with "Actual". {Same issue as [474:17] edit.} [480:32 15.5.5.9p2] Replace "Formal" with "Actual". {Same issue as [474:17] edit.} [483:17 15.9.2p2] {Empty edit} [485:9-21 15.10.4] Why did we invent the term "pending communication affector" for a concept that is identical to "pending input/output storage sequence affector"? Why not call them both "pending storage sequence affector"? {Only the restrictions are the same. The semantics are different. For example, the pending state for communications is not cleared by a WAIT statement.} [511:40+] Insert a list item: "o the value of the \cf{base_addr} member of a CFE_cdesc_t object if the object it describes has zero size (15.5.3);" {Already in Annex A at [512:8].} [512:10+] Insert a list item: "o the result of procedures defined by Fortran and procedures defined by means other than Fortran both performing input/output operations on the same external file (15.10.1);" {Already in Annex A at [509:23-24].}