J3/04-414 To: J3 From: Dan Nagle Subject: Simple ASSERT Date: 2004 October 25 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 processordent, 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 help programmers 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=] 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. Note that the assert-specifier-list is a list so future enhancements to the assert statement may add other specifiers without surprise or undue difficulty. 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 History: Submitted to J3 at meeting 170, simplified from the glom of 04-105, 04-142, 04-212, 04-219.