26-04-2005, 02:35 PM
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.)
\"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.)