ISO/IEC JTC1/SC22/WG5 N1882 Comments from Germany (DIN) on ISO/IEC PDTS 29113 1. (te) Assumed rank and the ALLOCATABLE or POINTER attribute Allowing the ALLOCATABLE or POINTER attribute for assumed-rank entities may cause a problem within Fortran in case a future extension is considered, which would allow entities to change rank at run time ("deferred-rank"). In this case, it would be preferable for a declaration REAL, DIMENSION(..), ALLOCATABLE :: X to denote a deferred-rank entity. Alternatively, a mechanism would be required (within Fortran) to disambiguate deferred-rank from assumed-rank entities during execution of the program. Therefore it is suggested that, until the Fortran facilities are properly defined, the ALLOCATABLE and POINTER attributes be prohibited for assumed-rank entities. Suggested edit: [p4, C535a]: before "CODIMENSION", add "ALLOCATABLE"; after "CODIMENSION", add ", POINTER, ". .............................................................................. 2. (te) Some missing rules for assumed-rank entities Some extensions from assumed-shape to assumed-rank appear to be missing; the suggested edits to N1830 are: (1) 12.5.2.4, line 2 of para 10: after "the contiguous attribute", add ", an assumed-rank entity with the CONTIGUOUS attribute which is associated with an actual array argument" (2) 12.5.2.4, para 18, C1239 (concerns ASYNCHRONOUS): replace the text "an assumed-shape ... attribute" by "shall not have the CONTIGUOUS attribute and be an assumed-shape array or an assumed-rank entity" (3) 12.5.2.4, para 18, C1240 (concerns ASYNCHRONOUS): replace the text "an array pointer ... attribute" by "shall not have the CONTIGUOUS attribute and be an array pointer, an assumed-shape array, or an assumed-rank entity" (For (2) and (3) this means that scalar actual arguments matching assumed-rank dummy arguments are included, but since we're excluding the attribute here, I think it does not matter. Having "assumed-rank entity which is associated with an array argument" would probably not be consistent with having a constraint). (4) 12.5.2.13, para 1, item (3) (b): replace "or an assumed-shape array" by "an assumed-shape array, or an assumed-rank entity" (5) 12.5.2.13, para 1, item (4) (b): replace "or an assumed-shape array" by "an assumed-shape array, or an assumed-rank entity" (6) C.9.4 para 2: replace "or an assumed-shape array" by "an assumed-shape array, or an assumed-rank entity" .............................................................................. 3. (te) Deferred vs. fixed length strings As noted on the interop-tr mailing list, specifying the elem_len argument to CFI_allocate gets into trouble if the argument describes a fixed length character entity. My opinion is that the elem_len argument should be removed from CFI_allocate because simply ignoring it for the case of fixed-length strings will not be sufficient if descriptors for deferred-length strings should also be creatable in C, and must therefore be disambiguable from those describing fixed-length strings. If support for deferred-length strings is to be retained, the suggestion is to do this in a way that can also handle other deferred parameters in the future; such parameters are regarded as opaque i.e., may not be directly extractable from the exposed part of the descriptor. An acceptable alternative of course is to limit the TR's support to fixed-length strings. Suggestion for changes to N1869 including deferred-length strings: [p12, third-to-last para]: After "Fortran lower bound.", add "For a C descriptor of an deferred character entity which has the ALLOCATABLE attribute and is unallocated, or is a disassociated pointer, the /elem_len/ member has the value zero." [p15]: Add a new error condition to table 5.3 "CFI_INVALID_PARAM The value supplied for a deferred parameter or its selection is not valid." [p17]: Modify the description of CFI_allocate as follows: (1) delete the /elem_len/ argument and its description (2) After "On successful execution ... is updated." add "If /dv/ describes a deferred-length character entity, /CFI_set_deferred_param/ shall have previously been invoked with /param_type/ equal to "char", and the /elem_len/ member is set to the /param_value/ provided in that invocation." [p18, first para]: Modify the description of CFI_deallocate as follows: After "On successful execution of CFI_deallocate, the C descriptor is updated." add "Any state tokens set via a previous invocation of CFI_set_deferred_param with /dv/ as its argument are deleted." [p18]: At the end of the description for the /elem_len/ argument of CFI_establish: After "character type and kind.", add "For a deferred-length character entity, /elem_len/ must have a value of zero." [p22]: Add a new function "5.3.5.10 int CFI_set_deferred_param(CFI_cdesc_t *dv, void *param_value, char param_type[]); Description: /CFI_set_deferred_param/ updates a C descriptor for a Fortran entity that has deferred length parameters. Formal parameters: /dv/ shall point to a C descriptor for an entity that has deferred length parameters. It is updated using information from the /param_value/ and /param_type/ arguments. It shall be an unallocated allocatable variable or a disassociated pointer. If /param_type/ has the value "char", it shall describe a deferred-length character entity declared in Fortran, or shall be a descriptor for a character entity produced by /CFI_establish/. /param_value/ provides a state token for the length parameter for a deferred-length character entity if /param_type/ has the value "char"; the provided value is then considered as being of type size_t *. <> /param_type/ provides the information on what kind of type parameter is being set. /CFI_set_deferred_param/ updates its C descriptor argument with the received state token if executed successfully. Otherwise, the C descriptor remains unchanged. If /dv/ was previously created via an invocation to CFI_establish(), is of a character type and has the /attribute/ CFI_attribute_pointer or CFI_attribute_allocatable, the invocation always concludes successfully and /dv/ becomes a descriptor for a deferred-length character entity. NOTE 5.11: Invoking /CFI_set_deferred_param/ on a deferred-length string with /param_type/ equal to "char" does not modify the /elem_len/ member of the descriptor. This modification is delayed to the allocation of the described entity." <> ....................................................................... 4. (te) Handling of non-interoperable procedure arguments in BIND(C) interfaces For specification of callback routines in the MPI-3 interface, it is considered desirable to allow non-interoperable procedure arguments in BIND(C) interfaces. By way of functionality, this would provide the analogous facility as the descriptorless TYPE(*) does for data. The syntax could be very simple: It would be sufficient to allow specifying the EXTERNAL attribute for a procedure dummy argument in a BIND(C) interface. Furthermore, a rule would be needed that if the actual procedure argument is non-interoperable, it is not allowed to invoke the procedure from C; if the actual procedure is interoperable, an invocation from C is permitted. (The callbacks could also use an interoperable callback, but that would require the use of TYPE(*), DIMENSION(*) dummy arguments in the callback, and therefore extensive changes in user-written callback implementations) (C4 is probably obsolete since the MPI-3 draft in its present state has chosen a different strategy; however a statement from J3 on whether this is feasible with sufficiently little work would be welcome).