Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082523 | emb-9 | Kim Barrett | P3 | Resolved | Fixed | team |
The STATIC_ASSERT macro attempts to produce a unique type name by macro splicing with __LINE__. However, the way that's presently being done is incorrect:
STATIC_ASSERT_FAILURE_ ## __LINE__
doesn't expand __LINE__, so we get STATIC_ASSERT_FAILURE___LINE__.
Doing this properly requires the use of a deferred concatenation macro, e.g.
#define CONCAT(X, Y) X ## Y
and
CONCAT(STATIC_ASSERT_FAILURE_, __LINE__)
However, there's a question as to whether we need the unique type name at all. If all the assertions succeed, the types are all the same.
None of our compilers presently complains about multiple identical typedefs; but maybe we don't have the right warnings enabled. Also need to check whether that's standards conforming.
Also need to look at the error messages for mix of pass and fail assertions, and multiple fail assertions.
STATIC_ASSERT_FAILURE_ ## __LINE__
doesn't expand __LINE__, so we get STATIC_ASSERT_FAILURE___LINE__.
Doing this properly requires the use of a deferred concatenation macro, e.g.
#define CONCAT(X, Y) X ## Y
and
CONCAT(STATIC_ASSERT_FAILURE_, __LINE__)
However, there's a question as to whether we need the unique type name at all. If all the assertions succeed, the types are all the same.
None of our compilers presently complains about multiple identical typedefs; but maybe we don't have the right warnings enabled. Also need to check whether that's standards conforming.
Also need to look at the error messages for mix of pass and fail assertions, and multiple fail assertions.
- backported by
-
JDK-8082523 STATIC_ASSERT use of __LINE__ is wrong
-
- Resolved
-
- relates to
-
JDK-8086027 Multiple STATIC_ASSERTs at class scope doesn't work
-
- Resolved
-