MISRA rule 89

[perrola]

Dear,

I have to design our new familly product SW platform.

To do this, we have introduce in our design the \"components set\" concept, that gathers components that have the same functionnal behaviour and that are interchangeable.
Let's take the example of a driver: we can have driver1 and driver2 that
are interchangeable, do the same job, and part of the same library. They
present the same interface.
During project instanciation from the SW platform, we choose one of them. To manage this, we plan to have a definition of the include file to avoid modifying a generic component that would call these drivers.

Code:

#define COMP_DRIVER     \"driver1.h\"

and in all the components that use this driver, we plan to include the
appropriate header file this way:

Code:

#include COMP_DRIVER

Is this a violation of the MISRA rule 89 ?

Defining the header file this way:

Code:

#define COMP_DRIVER     \"../driver1/driver1.h\"

Is this a violation of the MISRA rule 89 ?

Thank you for your answer.

Best regards

Laurent Perron

[walter.schilling@computer]

Based upon what I have seen with tools, most toolsets will flag this as a violation, which is the i9ntent of the rule.

While I have had to use such constructs myself (usually as a result of non-compliant compiler ionstallations and other reasons), using #define in a #include can lead to problems, especially with dependency generation, as I have seen some dependency generation tools not perform proper substitution when generating dependencies.

Hope this helps.

[heptagonal]

To: Laurent Perron,

I read with interest your question about combining #define symbols inside of #include statements. I agree with all of the comments by Walter Schilling in his reply to your post.

I would also like to add some additional comments of my own.

It has been my experience that during the evolution of a long duration project, it is often necessary to reorganize directory structures and/or physical locations of source files. It is extremely counterproductive if these sorts of administrative tasks impact the actual content of source files.

For managing includes, I have adotped a coding style that follows these four rules:

(1) Never use the form #include \"...\"

(2) Always use the form #include

(3) Only specify the exact filename inside of and DO NOT include any directory information whatsoever.

(4) Allow the compiler tools and/or operating system environment to resolve the included filename outside of the scope of the source code.

These rules accomplish the following:

(a) Files can be relocated and directories can be restructured without having to modify source code. This is particularly important when source code has been subjected to peer review and then archived in a version control system. Having to re-review and re-archive source files that have changed for trivial reasons is a monunmental waste of time.

(b) Portability is increased by keeping operating system dependencies in the specification of directory paths (and so forth) out of the source code. For example, a relative path such as ../thisstuff/thisfile will be correct in a UNIX or LINUX environment but incorrect in a Windows environment.

© Resolution of include file locations can be performed using directory search lists maintained by your local compiler, or even by symbolic references if your operating system supports this (UNIX/LINUX). This centralizes information about locations of files in one place instead of having references scattered throughout the source code files themselves.

I am interested in any comments that other developers might have with regard to the MISRA-C:2004 compilance (or non-compliance) of this approach to managing source file name resolution.

Best Regards,

-Jack D. Calderon
Heptagonal Technology

[perrola]

... for all these answers. They contain very interested remarks on this topic.

On my side, I had a look at the MISRA-C:2004 and it seems that the construction I proposed is accepted in rule 19.3.

Best regards

Laurent Perron

[perrola]

... for all these answers. They contain very interested remarks on this topic.

On my side, I had a look at the MISRA-C:2004 and it seems that the construction I proposed is accepted in rule 19.3.

Best regards

Laurent Perron

[misra-c]

We agree with previous post.