Does Rule 7.1, \"No octal constants (other than zero) and octal escape sequences shall not be used,\" permit the use of the null character, '\\0'? The normative and rule text exempt 0, per se, but make no mention about '\\0'. Prohibitting '\\0' runs, IMHO, contrary to the Principle of Least Surprise. Perhaps someone would show such kindness as to provide me with some clarity?
I appreciate your time in advance.
The normative text and the supporting text permit use of the octal constant 0 but do not afford the same special-case status to the octal escape \"\\0\". Neither 0 nor \"\\0\" has potential for undefined, implementation-defined or confusing behaviour. Therefore it is entirely reasonable for \"\\0\" to be permitted by this rule given that 0 is permitted. Accordingly, Rule 7.1 should be interpreted as permitting \"\\0\".
MISRA Reply Wrote:Neither 0 nor "\\0" has potential for undefined, implementation-defined or confusing behaviour. Therefore it is entirely reasonable for "\\0" to be permitted by this rule given that 0 is permitted. Accordingly, Rule 7.1 should be interpreted as permitting "\\0".
Does the same go for '\\00' and '\\000'?
There is a potential for confusing behaviour with the \"\\0\". My leaning is to not allow octal escape sequences. For example when embedding a nul character into a string, when the following characters are digits:
\"value1\\0value2\\0123\\0\"
This will result in a string with the values:
\"value1\" nul-char \"value2\" \"\\12\" \"3\" nul-char nul-char
This is probably not what most readers would first assume.
My reading of ANSI/ISO C 9899-1990 section 6.1.3.4 also indicates the hex escape sequence will also have problems, as a hex escape sequence is only terminated by a non-hex character. Without MISRA rule 7.1 it would be sensible to always require three character octal nul characters when embedding into a string. With this rule the simplest way I see to be compliant with MISRA would be:
#define NUL_CHAR_STR \"\\x00\"
\"value1\" NUL_CHAR_STR \"value2\" NUL_CHAR_STR \"123\" NUL_CHAR_STR
(Note that C90 6.1.4 requires escape sequences to be converted before concatenation.)