18-08-2015, 08:43 AM
I think that the undefined behaviour in question arises from this part of N1256, Section 6.7.4:
The undefined behaviour (caused by violation of a "shall" or "shall not" - see N1256, Section J.2, first bullet) can only arise if a function with external linkage, declared with the inline specifier, isn't defined in the same translation unit. So, this can't apply to functions with internal linkage.
The standard is explicit in stating that each copy of an inline function has its own static variables (N1256, Section 6.7.4, footnote 122) so I agree that there's certainly scope for unexpected behaviour as you suggest. Within a given translation unit, this could be avoided by declaring static objects at file scope, although this might violate Rule 8.9 (advisory). However, it wouldn't help when there are copies of the inline function in multiple translation units.
Therefore, I think that the rule is aimed at avoiding the undefined behaviour only and doesn't address the (possibly) unexpected behaviour. Avoiding storing state in inline functions would seem to be a good idea nonetheless.
So far as I am aware, there are no significant differences between N1256 and the published standard (as corrected).
Quote:For a function with external linkage, the following restrictions apply: If a function is declared with an inline function specifier, then it shall also be defined in the same translation unit.
The undefined behaviour (caused by violation of a "shall" or "shall not" - see N1256, Section J.2, first bullet) can only arise if a function with external linkage, declared with the inline specifier, isn't defined in the same translation unit. So, this can't apply to functions with internal linkage.
The standard is explicit in stating that each copy of an inline function has its own static variables (N1256, Section 6.7.4, footnote 122) so I agree that there's certainly scope for unexpected behaviour as you suggest. Within a given translation unit, this could be avoided by declaring static objects at file scope, although this might violate Rule 8.9 (advisory). However, it wouldn't help when there are copies of the inline function in multiple translation units.
Therefore, I think that the rule is aimed at avoiding the undefined behaviour only and doesn't address the (possibly) unexpected behaviour. Avoiding storing state in inline functions would seem to be a good idea nonetheless.
So far as I am aware, there are no significant differences between N1256 and the published standard (as corrected).
<t></t>