To: J3 Members J3/16-142r2 From: Van Snyder & Bill Long Subject: Comments on Clause 15 Reference: 16-007, 16-142, 16-160, 16-161. Date: 2016 February 09 Discussion ---------- This paper is a revision of 16-142. The edits from that paper, except for four, are divided into Group A, accepted edits, and Group N, those not accepted. Only the Group A edits should be made to 16-007. Two additional edits were moved to paper 16-161, and were later not accepted. The remaining two edits from 16-142 were typographical only and were moved to paper 16-160. Edits to 16-007 (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:26,28 15.2.3.5p5] Replace "FPTR" with "FUNPTR" twice. {The name can be anything. The choice of FUNPTR avoids confusion with the name of dummy arguments to C_F_PROCPOINTER description.} [461:29 15.2.3.5p6] Replace the first "FPTR" in para 6 with "CPTR". {Correct mistake in the current text. The result of C_FUNPTR is a C pointer.} [461:29-30 15.2.3.5p6] Replace the "where FPTR has" in para 6 with "where the FPTR argument has". {Clarify that the FPTR here is the argument to C_F_PROCPOINTER.} [464:0+17 NOTE 15.7] Replace "derived (via typedef) from short" with "defined as short (via typedef)". {The word "derived" is used in C for types refers to pointers. Defined is better here. Change subsequent wording to make it grammatically correct.} [475:20-21 15.5.5.3p2] Append "if \cf{dv->rank} > 0" twice. {The bounds arrays are ignored if the rank is zero. The "shall be the address of an array" requirement is excessive in the case of rank = 0.} [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.} ---End of Edits to 16-007---- Group N - Changes not accepted ------------------------------ Note to Editor: Do not make any of the changes indicated between here and the end of the paper. These are included only for documenting the disposition of the original paper edits. [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:6 15.2.3.3] Replace "will associate" with "associates". Replace "specify" with "specifies". {Statement is conditional on executing the example text. Current wording is correct.} [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,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. {Current wording is correct.} [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.} [472:21 15.5.4p9] Replace "which" with "that". {Current wording is correct.} [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.} [476:36 15.5.5.5p2] Replace "will be" with "is". {Conditional case. Current wording is correct.} [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.} [482:21+11,12,14 NOTE 15.33] Replace "will create" with "creates". Replace "will become" with "becomes" twice. {Current wording is correct.} [483:17 15.9.2p2] {Empty edit} [484:9 15.10.1p3] Replace "called" with "invoked". {The C standard uses "called".} [484:17 15.10.1p5] After "invoked as" insert "or during execution of". {Execution of a signal handler includes execution of any procedures it calls. So the change is not needed.} [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].}