20-08-2015, 12:09 PM
The footnote you mention, 122, seems to reinforce my impression that having static inline function definitions in a header is a very dangerous coding practice! So why is MISRA promoting that sort of coding?
The rationale mentions two scenarios, and making the inline function static is not a good solution to either one.
Your quote from section 6.7.4 paragraph 6 relates to the first scenario: declaring the function but not defining it. (If the definition is not in the translation unit, it shouldn't even compile, because of that "shall". But I suppose compilers do let you get away with stuff...)
But declaring the function static is not a good solution to that - the rule could just insist on the definition being provided! That's how extern inline functions are supposed to work, put the definition in the header, so the function can be inlined if the compiler thinks it can/should do so; put a declaration in one .c file to tell the compiler where to put the actual instance of the function, so that any translation unit in which the compiler didn't feel up to doing the inlining, has something to call.
Using extern means that the function cannot contain a modifiable object with static storage duration or refer to anything that has internal linkage (6.7.4 par 3) so it's safe to put the definition in the header file. But it's not safe to put the definition of an inline function with static storage duration in a header file, because if it's not extern, it can reference such things!
The rationale then goes on to refer to the fact that it is undefined whether the inline definition or a function call will be used. But making the function static is not a solution to that either! Even if the inline function is static, the inline is only a suggestion; the extent to which such suggestions are effective is implementation-defined (6.7.4 par 6 and footnote 121). So, even if it is static, the function may be inlined, or called; it is even possible that it could be inlined when the function is used in one place in the translation unit, and called in another, depending on context.
So I'm getting more and more convinced that rule 8.10 is just wrong. It will not make code safer, and could introduce bugs. Someone please convince me otherwise?
The rationale mentions two scenarios, and making the inline function static is not a good solution to either one.
Your quote from section 6.7.4 paragraph 6 relates to the first scenario: declaring the function but not defining it. (If the definition is not in the translation unit, it shouldn't even compile, because of that "shall". But I suppose compilers do let you get away with stuff...)
But declaring the function static is not a good solution to that - the rule could just insist on the definition being provided! That's how extern inline functions are supposed to work, put the definition in the header, so the function can be inlined if the compiler thinks it can/should do so; put a declaration in one .c file to tell the compiler where to put the actual instance of the function, so that any translation unit in which the compiler didn't feel up to doing the inlining, has something to call.
Using extern means that the function cannot contain a modifiable object with static storage duration or refer to anything that has internal linkage (6.7.4 par 3) so it's safe to put the definition in the header file. But it's not safe to put the definition of an inline function with static storage duration in a header file, because if it's not extern, it can reference such things!
The rationale then goes on to refer to the fact that it is undefined whether the inline definition or a function call will be used. But making the function static is not a solution to that either! Even if the inline function is static, the inline is only a suggestion; the extent to which such suggestions are effective is implementation-defined (6.7.4 par 6 and footnote 121). So, even if it is static, the function may be inlined, or called; it is even possible that it could be inlined when the function is used in one place in the translation unit, and called in another, depending on context.
So I'm getting more and more convinced that rule 8.10 is just wrong. It will not make code safer, and could introduce bugs. Someone please convince me otherwise?
<t></t>