2709. offsetof is unnecessarily imprecise

Section: 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.

1. 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. If type is notUse of the offsetof macro with a type other than a standard-layout class (Clause 9), the results are undefinedis conditionally-supported.193 The expression offsetof(type, member-designator) is never type-dependent (14.6.2.2) and it is value-dependent (14.6.2.3) if and only if type is dependent. The result of applying the offsetof macro to a static data member or a function member is undefined. No operation invoked by the offsetof macro shall throw an exception and noexcept(offsetof(type, member-designator)) shall be true.