J3/04-376 To: J3 From: Dan Nagle Subject: Simple ASSERT Date: 2004 September 9 With the wish list overfull, new ideas should be limited. This paper re-proposes the ASSERT statement, this time in a simplified form. The advantages of ASSERT are improved commentary and debugging. The disadvantage is that these may be done in other ways, but prehaps not quite so easily. Number: Title: Simplified ASSERT Statement Submitted By: J3 Status: For Consideration References: Fortran 2003 (DIS) Basic Functionality: An ASSERT statement has one required argument, COND, which shall evaluate to TRUE. What happens if the assertion is false is processor dependent, however, the expectation is that the program will produce an error message and halt. This behavior is left processor dependent so processors have the option of providing alternatives without being non-conformant. Rationale: Assertions aid debugging. Assertions also serve to document a program and verify that changes to program code don't violate assumptions originally made and that users are correctly using the code. Debugging code may always be added in the form of existing kinds of conditional blocks, but these may not be clearly distinguishable as debugging code. Assertions clearly are debugging code. Indeed, they constitute a distinct category of conditional code. While commentary may be expected to convey the true state of a program, haste may cause mere comments to be not updated to reflect the actual state of a program. Because assertions serve to debug the program, they may be kept in a more current state and therefore may document the program better, too. Estimated Impact: One new statement must be added to Section 8. No other changes are needed. Detailed Specification: The form of the proposed ASSERT statement is: ASSERT( ) is [COND=] or [UMSG= ] The COND= specifier identifies the which shall be true when the ASSERT statement is executed. There must be exactly one COND item on the list. If it is the first item on the list, the COND= may be omitted. When the is false, a message is written to ERROR_UNIT identifying the assertion as failing. When the USMG is present, it is a user's message. It is expected that the contains information helpful in identifying the cause of the failure and is written with the processor's message. UMSG is optional, there may be only one UMSG. With a Note something like this: The usual implementation is that when the is false when the ASSERT statement is executed, the processor will write to ERROR_UNIT a message and then the program terminates. It is most helpful if the message identifies the source file name and the line number whence the ASSERT statement came, the text of the , and an indication that an assertion failed. Halting may be the normal consequence of an ASSERT failure, however, the processor might provide a way to continue execution and also might provide a way to disable ASSERT checking on a program-unit basis when it isn't desired to revalidate trusted production codes. End of the Note. Examples: ASSERT( i_what > 0 ) when false, execution of this statement writes something like this to ERROR_UNIT: assertion failed: file: snafu.f, line: 42, i_what > 0 -- ASSERT( jrow /= krow, umsg= "duplicate rows in solver") when false, execution of this statement writes something like this to ERROR_UNIT: assertion failed: file: snafu.f, line: 42, jrow /= krow message: duplicate rows in solver -- ASSERT( umsg= "actual argument is a null pointer", & cond= associated( a_ptr) ) when false, execution of this statement writes something like this to ERROR_UNIT: assertion failed: file: snafu.f, line: 42, associated( a_ptr) message: actual argument is a null pointer History: Submitted to J3 at 170, simplified from the glom of 04-105, 04-142, 04-212, 04-219.