[C-safe-secure-studygroup] Rule 1.3 (undefined behaviour) vs Directive 4.1 (run-time failures)

Fulvio Baccaglini fulvio_baccaglini at programmingresearch.com
Thu Jun 28 12:04:51 BST 2018


Hi,

Following up from the meeting, with regards to the cross-talk between
Rule 1.3 "There shall be no occurrence of undefined or critical
unspecified behaviour" and Dir 4.1 "Run-time failures shall be
minimised", I think that it can be argued that it is possible to
violate both guidelines at the same time, based on:

* A note in Dir 4.1 says "the presence of a run-time error indicates a
violation of Rule 1.3"

* The amplification in Rule 1.3 refers to "rules" rather than
"guidelines" (= rules + directives) in: "Some undefined and unspecified
behaviours are dealt with specific rules. This rule prevents all other
undefined and critical unspecified behaviours".

But I think that Roberto's argument also holds: in Appendix H it says
"If a particular undefined behaviour has no entry in the "Guidelines"
column then an instance of that behaviour in a program is a violation
of Rule 1.3", and for instance in the entry for C99 Id 33 the
Guidelines column refers to Dir 4.1, implying that Rule 1.3 does not
apply because of Dir 4.1.

The rationale of Dir 4.1 focuses on the developer adding "dynamic
checks" to the source code where there is the potential for run-time
failures to occur.

I think that this can be related to the other issue we were considering
of what should a tool be required to do when it cannot establish
whether an undecidable rule is violated or not.

Rule 1.3 is undecidable, so in this case if a tool were to report a
potential undefined behaviour, this could be used as a trigger for the
developer to investigate whether a dynamic check should be added (and
where a dynamic check is added I would then expect the tool's
notification to clear).

Fulvio




More information about the C-safe-secure-studygroup mailing list