3

Why does MISRA recommends that an inline function be declared with static storage class? While the keyword inline is a hint to the compiler to replace all function calls with the actual function body, and the compiler may or may not perform it, how does giving internal linkage (static) or external linkage (extern) to a function affect the inline operation by the compiler?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Girish Onte
  • 107
  • 2
  • 8
  • 2
    It means that the function will appear in this file if it is needed. If you have `extern` (explicitly or implicitly), then you run into issues with different compilers doing different things, and with needing to ensure that some object file provides a definition for a non-inlined function. That's my practical spin on it — my computer with the MISRA standard on it is under repair so I can't check what MISRA itself says about it. See https://stackoverflow.com/questions/6312597/, https://stackoverflow.com/questions/48172290/, https://stackoverflow.com/questions/25000497/ for more information. – Jonathan Leffler Aug 06 '18 at 19:14
  • MISRA is no generally accepted. It's a private norm, not a standard. The rule above is questionable at beast, actually potentially harmful. If you want a rationale, read the docuemtns, if that's insufficient, ask the organisation. – too honest for this site Aug 06 '18 at 19:29
  • 1
    @JonathanLeffler: `inline` is just a hint to the compiler, so you are left to the compiler's heuristics anyway. Problem is, two pointer to different instances of the same `static inline` functions will compare not equal, while for `extern inline` they are guaranteed to comparre equal. Plus, `static inline` can create much more overhead. – too honest for this site Aug 06 '18 at 19:31
  • 2
    Comparing pointers to (possibly) inlined functions is essentially meaningless, @toohonestforthissite. If the function is inlined, there is no pointer to the function. If there are pointers to the function, then it isn't sensible to mark it for inlining. And MISRA is a standard; it is not published by ISO, or the IEEE, but it is a standard. – Jonathan Leffler Aug 06 '18 at 19:37
  • @JonathanLeffler: That's not correct. If you take the pointer of an `inline` function, the function is instanciated like a normal function and the address is taken. For functions with static linkage, this is the CU, so two pointers to instances of the same function compare unequal. That's not the case for `inline` functions with external linkage. Let that apart: the behaviour of compilers for `static` and external `inline` functions is well defined by the C standard. Not sure how this would be a problem. And please provide a reference to the standardisation organisation realeasing MISRA. – too honest for this site Aug 06 '18 at 19:40
  • Said that, modern compilers will ignore `inline` like they do for e.g. `register` wrt the initial meaning. – too honest for this site Aug 06 '18 at 19:44
  • @toohonestforthissite: MISRA is the Motor Industry Safety Research Association — https://www.misra.org.uk/. – Jonathan Leffler Aug 06 '18 at 19:57
  • @toohonestforthissite: I can't immediately recognize what you mean by 'CU' in your comment about addresses of inline functions (unless you mean something like 'compilation unit', which is normally called the TU or 'translation unit' because that's the term used by the C standard). I stand by "it does not make much sense to take the address of a function that you want to be inlined" — you may dispute that, but I think it is a valid observation. That doesn't say you can't do it; just that it is not sensible to do so. – Jonathan Leffler Aug 06 '18 at 19:59
  • @JonathanLeffler: I know very well. And while the motor industry defines major parts of the climate politics in Germany and the US and is deeply woven with politicians (to say the most friendly), they are not a governmental institution - yet. The rule above is one reason they are not well acceepted by experienced developers (another is they have just reached the 19 year old C99 with MISRA 2012). – too honest for this site Aug 06 '18 at 20:02
  • @JonathanLeffler: Compilation Unit, yes, sorry I should have used TU indeed. Point is, you should be able to use `inline` functions like ever other. The code should not run different whether `inline` or not. If you rely on the timing optimisation, you can't rely on `inline` at all, no matter the linkage, but have to use compiler-specific pragmas/attributes/etc. I also used `static inline` until I learned how to properly use `extern inline`. Fact is, this has been defined well with C99. So maybe this rule is some relic in MISRA. That's the best explanation for this rule. – too honest for this site Aug 06 '18 at 20:03
  • 3
    I'm not sure how this is an "opinon-based" question. The answer is copy/pasted right from the MISRA document. There is no opinion involved. That said, I'd agree that it's probably not a high value question or answer. – Michael Burr Aug 06 '18 at 22:43
  • @MichaelBurr: The rationale you posted does exactly *not** explain anything. A function has to be defined, whether `inline` or not, internal or external linkage does not make a difference. TGhat makes the first part pointless. The second part is about timing. As `inline` is only a hint to the compiler and has no guaranteed behaviour (actually modern compilers mostly ignore it like `register` (wrt optimisations), the linkage also doesn't matter. Leave the problem comparing pointers to the function, which makes external linkage clearly the less surprising approach. – too honest for this site Aug 06 '18 at 22:55
  • @MichaelBurr: Briefly: the given rationale is pointless, so we can only speculate. As MISRA (and e.g. Jonathan Leffler) has apparently a different opinion, than me, the question is POB and purely speculation about their motivation. Finally, I still have to see a true argument for this rule - apart from a forgotten legacy. – too honest for this site Aug 06 '18 at 22:56
  • Voting to re-open this. The question is specific and there is no room for opinions. That some users chose to derail the topic in a lengthy comment debate is no fault of the OP. – Lundin Aug 07 '18 at 06:37
  • @toohonestforthissite Here, MISRA-C is merely repeating what the C standard lists as undefined behavior. MISRA tries to ban all cases of undefined behavior from C programs, which is why this rule exists. See C11 6.7.4. – Lundin Aug 07 '18 at 06:37
  • That compilers do not have to honour `inline` is one of the (many) stupidities of the C standard... – Andrew Aug 07 '18 at 07:35
  • @Andrew: Definitively not! Most other languages leeave this to the compiler completely, they don't even have an `inline`. The general rule is to trust your compiler. Said that: for most modern architectures, if you rely on this optimisatiion in your code, you are already on the edge and should think about your design. – too honest for this site Aug 07 '18 at 11:00
  • @Lundin: Asking for the motivation of a private organisation is very well OT and POB. OP should ask the authors. – too honest for this site Aug 07 '18 at 11:02
  • 3
    @toohonestforthissite No that's nonsense. You are aware that ISO is (quoting their web site): "ISO is an independent, non-governmental international organization". Using your arguments, questions regarding ISO 9899 is off-topic as well, since ISO is a private organisation. – Lundin Aug 07 '18 at 14:03
  • @Lundin: Nevertheless it's accepted by international agreements between states (I was wrong about government, though, it's the legislative, not the executive, of course). MISRA is just a private organisation by some car manufacturers. And their norms are not generally accepted - oppositve there is very rfundamental and justified critique about their blind application to coding. (nevertheless it's a good reading, just with eyes open and thouightfully) – too honest for this site Aug 07 '18 at 14:17
  • 2
    @toohonestforthissite Microsoft is also a private organisation, so questions about Windows programming are also off-topic then, as Windows is not generally accepted. This is just silly. --> – Lundin Aug 07 '18 at 14:31
  • 1
    MISRA-C is de facto standard in the whole embedded systems branch: automotive, aerospace, med-tech, industrial etc etc. If you follow MISRA-C to 100%, blindly, without understanding the reason behind the rules, you are doing it wrong - MISRA themselves has pointed out numerous times that this is not the way to go. See for example this paper: [MISRA-C:2012 Cure or Curse](https://www.safetycritical.info/library/presentations/MISRA-C-curse-or-cure.pdf) by Chris Hills who is a member of the MISRA-C committee. – Lundin Aug 07 '18 at 14:32
  • TooHonest - MISRA was started by a group of car companies (in 1994) but nowadays is much more widespread than that... [see my profile for disclaimer] – Andrew Aug 08 '18 at 07:13
  • PS: "The general rule is to trust your compiler." ??? Trust, maybe, but verify. – Andrew Aug 08 '18 at 08:55

1 Answers1

2

MISRA C:2012 gives the rationale for rule 8.10 as:

Rationale

If an inline function is declared with external linkage but not defined in the same translation unit, the behaviour is undefined.

A call to an inline function declared with external linkage may call the external definition of the function, or it may use the inline definition. Although this should not affect the behaviour of the called function, it might affect execution timing and therefore have an impact on a real-time program.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • Thi rationale (and the rule) is completely pointless and possibly even dangerous. `inline` is just a hint and modern compilers will inline functions or not at their own discretion, no matter `inline` or not. It's dangerous, because a pointer comparison for the `static inline` functions will result in different pointers, while using normal external linkage will guarantee a single instance, i.e. pointers comparing equal for the same function. – too honest for this site Aug 06 '18 at 19:27
  • I'm just quoting what's in the document. Also keep in mind that compilers can inline if possible regardless of the `inline` keyword. The `inline` keyword really just makes it so ODR is not in effect for that function (ie., `inline` makes it OK to have multiple definitions of the function - as long as they're identical). I can't speak to the level of risk that mentioned in the rationale for timing. – Michael Burr Aug 06 '18 at 22:38
  • Point is:`inline` is merely a hint and if your timing depends on it, you need to use compiler-specific features or manually "inline". I read this rule to use `static` as opposed to `inline` functions with external linkage. And that's where the rule is just ridiculous. As I stated in a different comment, this can only be explained as a relic of the previous MISRA version. Otherwise it's another reason to take MISRA not as a religion and not follow it blindly. And tht's the general criticism to MISRA. Said that: we can't really explain **why** they state it, the rationale is nonsense. – too honest for this site Aug 06 '18 at 22:46
  • Supposedly this is undefined behavior as per C11 6.7.4. Annex J of the standard lists this as UB: "A function with external linkage is declared with an inline function specifier, but is not also defined in the same translation unit". MISRA is merely repeating the C standard. – Lundin Aug 07 '18 at 06:35
  • 1
    If you want a pointer to a function, then (surely) it is irrational to make that function `inline`? – Andrew Aug 07 '18 at 07:32
  • @Lundin: This is obvious, but I don't see how this is a problem at all. `extern inline void f(void);` will create the instance of the function (the one for a normal call) from the `inline` defin ition in the same TU. Of course you have to have the definition available; but that's needed for `static inline` as well. – too honest for this site Aug 07 '18 at 10:55
  • @Andrew: The caller should not have to care about whether a function is declared `inline` or not. Expecially for a library, there can arise the problem to use a function pointer, yet one wants the function inlined for direct calls (consider OOP for example). Nevertheless, I'm willing both linkages are acceptable, there is just no advantage for local linkage, but therte are arguments against it. – too honest for this site Aug 07 '18 at 10:58
  • @toohonestforthissite: If a function is declared `static inline` within a translation unit where it used, but there is no definition in that same translation unit, a compiler is required to squawk. If it were declared `inline` but with external linkage, a conforming compiler would be allowed to silently issue bogus code. Any halfway-decent build system should squawk in that scenario; the only reason I can think of that one wouldn't would be if a linker lacked a means of properly ignoring all but one definition with attached content, but instead treated... – supercat Aug 07 '18 at 22:39
  • ...each inline declaration as a declaration without content, and the definitions as generating a module-specific symbols which are forced to be placed consecutively starting at the symbol associated with the inline function. If there is no inline function, the inline symbol would end up getting associated with unrelated code. – supercat Aug 07 '18 at 22:42