Rule 19.3 - #include... - what about directories?

[SafeT]

Hi,

Question about rule 19.3 -

I read this rule as forbidding constructs such as:

Code:

#include "foo/bar/baz.c"

and especially things like

Code:

#include "/usr/local/include/baz.h"
#include "C:/Windows/blah/baz.h"

because there is directory information following the #include keyword (it's not just a filename).

It's not clear to me whether or not the above example would violate rule 19.3 - can you please weigh in?

I think the use of absolute *or* relative directories on a #include line is a maintenance nightmare and can lead to unintended (read: incorrect) header files being included, especially as code is refactored and as source files are moved around.

My opinion (and my experience in safety-critical systems) is that #include directives should only specify a filename, not a path of any kind, and the build configuration should specify the appropriate directories to search, and in what order.

Can you please comment?

(David (or anyone from MISRA)) - I have some comments (such as this one) regarding the review draft copy of MISRA-C3, but I missed the deadline of May 31 for submitting comments. Is it too late? You can contact me through the email on my account or PM if that is better, thanks!)

[misra-c]

The rule is not intended to disallow directory components in a filename, whether absolute or relative. It makes no assumptions at all about the how the filename is used because the method by which it identifies a file, including the locations searched, is implementation-defined.