Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Rule 19.3 - #include... - what about directories?

Question about rule 19.3 -

I read this rule as forbidding constructs such as:
#include "foo/bar/baz.c"
and especially things like
#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!)
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.
Posted by and on behalf of the MISRA C Working Group

Forum Jump:

Users browsing this thread: 1 Guest(s)