08-04-2009, 08:02 PM
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
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
<t></t>