ISO/IEC JTC1/SC22/WG5 N2059 UK PROPOSALS FOR REVISION OF FORTRAN 2008 SUBMITTED TO WG5, AUGUST 2015 The BSI Fortran panel wishes to submit the following proposals for the revision of Fortran 2008 for consideration by WG5. To avoid possible confusion, they are numbered consecutively from the items in WG5-N2016. They are arranged in order of subclause, not in order of priority. --------------------------------------------------------------------------- Number: UK-23 Title: Remove unnecessary constraints on stop codes. Status: For consideration Comment: This was originally proposed by Damian Rouson (Sourcery Inc) Basic Functionality: Add ability to execute STOP and ERROR STOP statements with a non-constant stop-code. Rationale: (a) There is no significant reason to require the stop-code in a STOP or ERROR STOP statement to be constant. (b) It is tedious when writing error checks to have to expand what would be a simple one-line logical IF into a 4-line IF construct that first prints a string that is variable (e.g. a dummy argument) and then executes a STOP or ERROR STOP statement. (c) It is not possible to return a variable process exit status from a Fortran program via STOP or ERROR STOP. This may be desirable, for example, when a program executed via EXECUTE_COMMAND_LINE fails, in which case one might wish to exit with the same exit status as the failed program. This functionality is frequently accessible by using the C "exit" function, but that is not guaranteed to be available. (d) In the case of error termination with ERROR STOP in a pure procedure, it is not possible to provide more information that might indicate what the problem is or whence it was called, as external file output is not allowed there. Formal Specification: Permit non-constant stop codes in both STOP and ERROR STOP. Syntax: Change the productions to , and to . Edits to 15-007r1: [intro] Insert new bullet point and feature description: "\item Execution control: A STOP or ERROR STOP statement can have a nonconstant stop code.". [189:17-18] 8.4 STOP and ERROR STOP statements, In R851 change "" to "" and "" to "". That is, remove the word "constant" from the BNF for twice. --------------------------------------------------------------------------- Number: UK-24 Title: Remove anomaly in provision of error messages Status: For consideration Comment: This was originally proposed by Bernard Pichon, (CNRS - Observatoire de la Cote d'Azur) Basic Functionality: Ability to retrieve error messages for intrinsic procedures with STATUS arguments. Rationale: It is anomalous that it is possible to retrieve error messages from the processor for I/O routines, via optional argument IOMSG, for memory and image control routines via argument ERRMSG, and for EXECUTE_COMMAND_LINE via argument CMDMSG, but not for the three GET_ ... subroutines which simply return a processor-dependent integer value to indicate a failure. Formal Specification: Add an optional argument to each of the intrinsic subroutines GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE in a manner analogous to the CMDMSG argument for EXECUTE_COMMAND_LINE. In the case of a "warning" situation (that would assign -1 to STATUS), ERRMSG shall be left unchanged. Syntax: The new argument shall be called ERRMSG, and shall be added to the end of the existing argument list (so that there will be no compatibility issue). Edits to 15-007r1: [xviii] Introduction, p2, bullet "Intrinsic procedures and modules", Insert new feature description "Access to error messages from the intrinsic subroutines GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE, is provided by the optional ERRMSG argument." [327] 13.5 Standard generic intrinsic procedures, Table 13.1, In the GET_COMMAND row, after 'STATUS' add ', ERRMSG'. In the GET_COMMAND_ARGUMENT row, after 'STATUS' add ', ERRMSG'. In the GET_ENVIRONMENT VARIABLE row, after 'TRIM_NAME' add ', ERRMSG'. [361:3] 13.8.75 GET_COMMAND, heading, after "STATUS" add ", ERRMSG". [361:19+] 13.8.75 GET_COMMAND, p3 Arguments, insert new argument description at the end of the paragraph: "ERRMSG (optional) shall be a default character scalar. It is an INTENT (INOUT) argument. It is assigned a processor-dependent explanatory message if the command retrieval fails. Otherwise, it is unchanged." [361:32] 13.8.76 GET_COMMAND_ARGUMENT, heading, after "STATUS" add ", ERRMSG". [362:21+] 13.8.76 GET_COMMAND_ARGUMENT, p3 Arguments, insert new argument description at the end of the paragraph: "ERRMSG (optional) shall be a default character scalar. It is an INTENT (INOUT) argument. It is assigned a processor-dependent explanatory message if optional argument STATUS is, or would be if present, assigned a positive value. Otherwise, it is unchanged." [362:34] 13.8.77 GET_ENVIRONMENT_VARIABLE, heading, after "TRIM_NAME" add ", ERRMSG". [363:12+] 13.8.77 GET_ENVIRONMENT_VARIABLE, p3 Arguments, insert new argument description at the end of the paragraph: "ERRMSG (optional) shall be a default character scalar. It is an INTENT (INOUT) argument. It is assigned a processor-dependent explanatory message if optional argument STATUS is, or would be if present, assigned a positive value. Otherwise, it is unchanged." ---------------------------------------------------------------------------