0

Is using #include "component.c" considered bad practice or is there any misra standard rule violation? (potentially rule 3-3-1)

So far, I understand that it is a commonly categorized as bad practice but can be used in certain scenarios, would it be any particular concern for safety-critical applications?

Misra rule 3-3-1 states that Objects or functions with external linkage shall be declared in a header file

πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
arturo_drt
  • 23
  • 1
  • 2
    Yes, that's worst practice, and will at least summit in linker errors. – πάντα ῥεῖ Mar 31 '23 at 15:24
  • 5
    It's generally bad practice for all C programming, not just MISRA. You use linking to combine the result of compiling separate C files. – Barmar Mar 31 '23 at 15:24
  • 1
    I don't know how this practice could enhance any safety whatsoever. Don't do it. – Jabberwocky Mar 31 '23 at 15:40
  • 2
    Yes, including `.c` files is generally considered bad practice. However, there are very specific cases where it can be a good option. In those cases, I sometimes prefer to give the file a different extension, e.g. `.inc` to indicate that it is not a stand-alone `.c`-file. – nielsen Mar 31 '23 at 16:45
  • There is no MISRA C 3-3-1. Are you using C or C++? You need to know which programming language you are programming in before attempting more advanced things like MISRA compliance. – Lundin Apr 03 '23 at 06:15
  • As for safety-related programming, you need to be able to make a very solid argument for any scenario where you deviate from best practices. I don't really see how you'd manage to pass a code review making such an argument, let alone 3rd party type approval. – Lundin Apr 03 '23 at 06:22

5 Answers5

1

When you write a program like that, it is called a unity build. A good example of such a program is the compiler for the Odin programming language. So it can be done, but like anything else, there are tradeoffs.

pros

  • It puts more source into a single translation unit. This can help optimization, similar to how link-time-optimization works since the compiler can actually see the source from functions in other C files.

  • Less clutter in project files (less headers), and therefor, less repetition.

  • A greatly simplified build; It may be as easy as building only one file even if many files are in the project.

cons

  • Harder to understand for co-workers who use more common practices.

  • You can no longer define a static variable with a very generic name in a C file, because that C file could be part of a bigger translation unit. You will wind up with more verbose variable names.

  • It will generally slow down the build. Build systems (like make), can speed up compilation by only re-compiling what is dependent on all changes. If you are combining things into a single translation unit, the whole thing will need to build for every change. In a big project, this will lead to more memory consumption during the build.

  • You cannot parallelize the build.

Does this violate MIRSA?

I don't actually know, but it doesn't violate the rule you posted:

Misra rule 3-3-1 states that Objects or functions with external linkage shall be declared in a header file

By including a C file, you know longer have external linkage because they are in the same translation unit.

Jason
  • 2,493
  • 2
  • 27
  • 27
  • I never heard the term "unity build" before. I guess you learn something new every day. Going by the description on Wikipedia, however, a unity build is a specific use case for `#include`ing .c files, not a term describing the practice in general. In that case, I don't think it's quite right to say "When you write a program like that, it is called a unity build." – John Bollinger Mar 31 '23 at 15:55
  • I don't believe this is viable as the only build mode. Perhaps only for release builds, where build incremental build speed isn't as important. – HolyBlackCat Mar 31 '23 at 16:04
1

You are referencing the MISRA C++ standard not the MISRA C standard. In the MISRA C++ standard rule 3-1-1 does not restrict you from #include-ing C files in other C files, because any C file may include one another and not declare anything as having external linkage. The rule/requirement is about external linkage, not about C file inclusion. I believe that if they were to add a rule for including other C files it would be under section "Source file inclusion" rules 16-2-X, but i have just checked and there is nothing about including other C files. Personally, i dont mind including other C files because i see #include as just a copying and pasting operations to be used however you see fit.

Richard Bamford
  • 1,835
  • 3
  • 15
  • 19
0

It is also a matter of security in terms that you might not want to provide your code, so you just give the header and the object files

Dimitris Gavriil
  • 20
  • 2
  • Not sure how this addresses the question, about `#include`-ing a C file? – Andrew Apr 02 '23 at 09:33
  • if you #include .c file you need to have it, so you need to have the code, but if you #include .h file you just need to have the header file and the the object file to give it for link. – Dimitris Gavriil Apr 02 '23 at 10:33
0

Is using #include "component.c" considered bad practice

Generally speaking, yes.

Usually, the preprocessor's file-inclusion feature is reserved to support factoring common declarations into their own files, so that they don't need to be duplicated in multiple sources. Such factoring provides huge benefits for maintainability in all but the smallest projects, and it is a near-requirement for libraries to be usable. A file containing only such declarations is conventionally called a "header", and is conventionally named with a .h suffix. In this sense, then, the issue is partially about file naming and programming patterns.

On the other hand, C source files containing function or object definitions (as opposed to declarations) are conventionally named with a .c suffix. The C language forbids multiple external definitions of the same identifier (function or variable name) in the same program, so such .c files cannot be #included into more than one translation unit contributing to a program, and if they are included into even one, then they must not also be compiled directly. The usual way to build a program from multiple .c files is to compile them independently and then link them together.

Provided one is sure to avoid duplicate definitions, it is not inherently wrong to #include one .c file into another. But this makes sense only as a special-purpose arrangement. It creates extra risk, and it provides no particular advantage as far as the language specification goes. Also, because it runs contrary to convention, it tends to surprise and confuse developers -- maybe even more experienced future you.

is there any misra standard rule violation? (potentially rule 3-3-1)

It does not inherently violate MISRA rule 3-3-1, but it makes it less painful to write code that does violate that rule. That is by making it feasible to have all the needed external declarations in a single .c file plus its inclusions, instead of providing a separate header.

I don't see any other MISRA-2012 rule that such an inclusion would violate. But that would not hold much water with me in code review.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
0

Rule 3-1-1 is a MISRA C++:2008 rule

The applicable MISRA C:2012 guidelines are (probably) Rules 20.2 and 20.3 - which do not prohibit the use of .c extensions.

--

In MISRA C:2004, Rule 8.5 prohibited source code in a header file (assumed to be a .h file). This Rule was dropped for MISRA C:2012 to permit the use of inline functions.

--

Personally, I think #include-ing a .c file is a bad idea - it suggests a mis-understanding of the language, the compiler and the linker.

If you do so, the expanded file would count as a Single Translation Unit for analysis purposes...

(see profile for Affiliation)

Andrew
  • 2,046
  • 1
  • 24
  • 37