16-10-2015, 05:21 PM
Thanks, that does help me understand what is going on, and make me comfortable in getting a deviation from this rule for my code.
May I assume the Note refers to the first post from Steve Montgomery in this thread? He quotes 6.7.4.6, not 6.7.4.5 as implied by the Note. His quote says that an inline function with external linkage is to be defined in the same translation unit. And, yes, a function with internal linkage cannot violate the clause he quotes, because you cannot use such a function without having the definition in the translation unit. But the problem also does not arise if the function definition is in the .h file, with one extern declaration in one .c file which also #includes the header, to indicate the location of the external definition. In this case too, the definition is in the translation unit containing the declaration.
(6.7.4.6 also implies that there could be different internal and external definitions for an inline function with external linkage. I hope that is not what we are talking about. Having the definition in the .h file will avoid that.)
But the implementation-defined behaviour of section 6.5.4.5 remains. The function may be expanded inline by the compiler, or there may be an instance of the function, which is called - regardless of whether the function has internal or external linkage. This is true at least of both of the compilers I use (IAR, GCC), so I have to live with it even if your reading of the standard suggests it should be otherwise for static functions. (Are there any readily-available compilers that always inline all static inline functions, regardless of optimisation settings or function complexity?)
Now, as you say, it is true that putting static inline functions in header files does not exhibit unspecified or undefined behaviours. Neither does using a simple statement with no braces as the body of an 'if', but I wouldn't do that either. Putting static inline functions in a header can lead - and for me, has led - to a bug, which is why I came here in the first place. So a deviation looks like my best option.
May I assume the Note refers to the first post from Steve Montgomery in this thread? He quotes 6.7.4.6, not 6.7.4.5 as implied by the Note. His quote says that an inline function with external linkage is to be defined in the same translation unit. And, yes, a function with internal linkage cannot violate the clause he quotes, because you cannot use such a function without having the definition in the translation unit. But the problem also does not arise if the function definition is in the .h file, with one extern declaration in one .c file which also #includes the header, to indicate the location of the external definition. In this case too, the definition is in the translation unit containing the declaration.
(6.7.4.6 also implies that there could be different internal and external definitions for an inline function with external linkage. I hope that is not what we are talking about. Having the definition in the .h file will avoid that.)
But the implementation-defined behaviour of section 6.5.4.5 remains. The function may be expanded inline by the compiler, or there may be an instance of the function, which is called - regardless of whether the function has internal or external linkage. This is true at least of both of the compilers I use (IAR, GCC), so I have to live with it even if your reading of the standard suggests it should be otherwise for static functions. (Are there any readily-available compilers that always inline all static inline functions, regardless of optimisation settings or function complexity?)
Now, as you say, it is true that putting static inline functions in header files does not exhibit unspecified or undefined behaviours. Neither does using a simple statement with no braces as the body of an 'if', but I wouldn't do that either. Putting static inline functions in a header can lead - and for me, has led - to a bug, which is why I came here in the first place. So a deviation looks like my best option.
<t></t>