Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8083204 | emb-9 | Kim Barrett | P4 | Resolved | Fixed | team |
The present implementation of STATIC_ASSERT() (in utilities/debug.hpp) expands into a variable declaration within a do { } while (0) block.
The use of the do/while block is to uniquify the variable name, so that it won't conflict with later uses of the macro in the same block. However, as a result of this implementation, the macro can only be used in a context where a statement is permitted. There are many use cases for static assertions that occur at global/namespace scope or class scope.
The uniquification can instead be accomplished by splicing the __LINE__ number on to the name being declared. [The only place that won't work is if there are multiple assertions the same scope, all the result of a single macro expansion. If that situation ever arises, the way to deal with it is to add a variant assertion macro that takes an additional identifier argument.]
Because the current implementation expands to a variable declaration, it is conditionalized for PRODUCT/non-PRODUCT, with the PRODUCT expansion being empty, e.g. no checking in PRODUCT builds, which is unfortunate.
However, it is possible to instead use a typedef as the expansion, eliminating any code generation. This would allow checking to be done during PRODUCT builds with no runtime cost.
The use of the do/while block is to uniquify the variable name, so that it won't conflict with later uses of the macro in the same block. However, as a result of this implementation, the macro can only be used in a context where a statement is permitted. There are many use cases for static assertions that occur at global/namespace scope or class scope.
The uniquification can instead be accomplished by splicing the __LINE__ number on to the name being declared. [The only place that won't work is if there are multiple assertions the same scope, all the result of a single macro expansion. If that situation ever arises, the way to deal with it is to add a variant assertion macro that takes an additional identifier argument.]
Because the current implementation expands to a variable declaration, it is conditionalized for PRODUCT/non-PRODUCT, with the PRODUCT expansion being empty, e.g. no checking in PRODUCT builds, which is unfortunate.
However, it is possible to instead use a typedef as the expansion, eliminating any code generation. This would allow checking to be done during PRODUCT builds with no runtime cost.
- backported by
-
JDK-8083204 Improve STATIC_ASSERT
-
- Resolved
-
- relates to
-
JDK-8086027 Multiple STATIC_ASSERTs at class scope doesn't work
-
- Resolved
-