This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.
offsetof is unnecessarily impreciseSection: 17.2 [support.types] Status: C++17 Submitter: Richard Smith Opened: 2016-05-10 Last modified: 2017-07-30
Priority: 2
View all other issues in [support.types].
View all issues with C++17 status.
Discussion:
Per 17.2 [support.types]/4:
"The macro
offsetof(type, member-designator)accepts a restricted set of type arguments in this International Standard. If type is not a standard-layout class (Clause 9), the results are undefined. [...]"
Implementations in practice interpret this as meaning that the program is ill-formed for classes that are not standard-layout, but several implementations allow additional types as an extension (rejected in their "strictly conforming" modes).
It would seem superior to specify that implementation-defined extensions are permitted, and that the implementation must give a correct answer for any type that it chooses to accept.[2016-05 Issues Telecon]
People were worried about the requirement to report errors implied by 'conditionally supported'.
[2016-06 Oulu]
The concern about errors appears to be less severe that we thought. Moving to Ready.
Friday: status to Immediate
Proposed resolution:
This wording is relative to N4582.
Change in 17.2 [support.types]/4:
-4- The macro
offsetof(type, member-designator)accepts a restricted set of type arguments in this International Standard.IfUse of thetypeis notoffsetofmacro with atypeother than a standard-layout class (Clause 9), the results are undefinedis conditionally-supported.193 The expressionoffsetof(type, member-designator)is never type-dependent (14.6.2.2) and it is value-dependent (14.6.2.3) if and only iftypeis dependent. The result of applying theoffsetofmacro to a static data member or a function member is undefined. No operation invoked by theoffsetofmacro shall throw an exception andnoexcept(offsetof(type, member-designator))shall betrue.