Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Rule 19.3 - #include... - what about directories?
#1
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!)
<t></t>
Reply
#2
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
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)