+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17)
+---- Forum: 6.19 Preprocessing Directives (https://forum.misra.org.uk/forumdisplay.php?fid=43)
+---- Thread: Rule 19.2 + TC1 (/showthread.php?tid=642)
Rule 19.2 + TC1 - William Forbes - 01-04-2009
Hi,
The Technical Corrigendum 1 now allows the \ character to be used in a file name path without the need for a deviation.
So what file will be included in the following:
Code:
#include "test\x61test.h"The C standard says that this is undefined.
Rule 1.2 bans undefined language features and thus a deviation is still required!
What is the point in now allowing undefined language features in one rule to avoid the need to deviate when using a system that does not allow one to write compliant code only to need a deviation against another rule. TC1 does not rescind rule 1.2?
William Forbes
Re: Rule 19.2 + TC1 - misra-c - 08-04-2009
There is an anomaly with this rule which was recognised when TC1 was being drafted. The aim of permitting the use of '\' in include file names without deviating Rule 19.2 was to acknowledge that some implementations provide no other means of separating directory and file names.
While you can use '\' without deviating Rule 19.2 you will, as you point out, strictly speaking violate Rule 1.2. For clarity and completeness you should document the decision to permit use of '\'. You could, if you wish, treat this as a violation of Rule 1.2.
This topic will be reviewed during drafting of the next version of the MISRA C Guidelines.
Re: Rule 19.2 + TC1 - William Forbes - 08-04-2009
Hi
Thanks for clearing that up.
In my opinion, directory name should not be needed.
Most compilers allow a search path to be specified via the command line.
Then when files are rearranged (perhaps when used on another project) it is simply a case of modifying the Make file instead of all of the #include statements in all of the source files.
It also avoids the undefined behaviour.
The problem with the \ character is that it could start an escape sequence. In my example there were at least 2 possible files that could have been included (that's why the behaviour is undefined).
At least with the / character there is not the ambiguity with escape sequences (although the behaviour is still undefined). One should respect the origins of the C language and realise that / has always been the directory separator. DOS based systems came up with \ as a directory separator to throw the spanner in the works!
In my experience, most implementations will treat both \ and / as a directory separator so if one must be used the I would suggest that / is used.
It is simply not possible to specify a directory without violating rule 1.2!
I strongly feel that MISRA should not be compromised simply to pander to a compiler and/or programmers who can't be bothered to do things correctly :-)
I would go as far to request that MISRA rules ban directory information in #include files.
Also It may be worth noting that the C standard does not guarantee any more that 6 character significance in file names (no guarantee of case sensitivity) and only a single character file extension and hence it is wise to ensure that all file names are unique in the first 6 characters and only have a singe extension (.c or .h I would suggest).There are still some DOS tools around that mess long file name up and only leave the first 6 characters!
Cheers,
William Forbes
Re: Rule 19.2 + TC1 - misra-c - 02-06-2009
William Forbes Wrote:I strongly feel that MISRA should not be compromised simply to pander to a compiler and/or programmers who can't be bothered to do things correctly :-)Agreed - this is our policy.
Quote:I would go as far to request that MISRA rules ban directory information in #include files.We will certainly consider this.