This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-12-19

1511. const volatile variables and the one-definition rule

Section: 6.3  [basic.def.odr]     Status: CD3     Submitter: Richard Smith     Date: 2012-06-18

[Moved to DR at the April, 2013 meeting.]

One of the criteria in 6.3 [basic.def.odr] paragraph 6 for when a entity is allowed to have multiple definitions is:

in each definition of D, corresponding names, looked up according to 6.5 [basic.lookup], shall refer to an entity defined within the definition of D, or shall refer to the same entity, after overload resolution (12.2 [over.match]) and after matching of partial template specialization (13.10.4 [temp.over]), except that a name can refer to a const object with internal or no linkage if the object has the same literal type in all definitions of D, and the object is initialized with a constant expression (7.7 [expr.const]), and the value (but not the address) of the object is used, and the object has the same value in all definitions of D; and

This wording is possibly not sufficiently clear for an example like:

  const volatile int n = 0;
  inline int get() { return n; }

Presumably this code could not appear in multiple translation units, because the requirement that n “has the same value in all definitions” cannot be satisfied (the value of a volatile variable can change “by means undetectable by the implementation,” per 9.2.9.2 [dcl.type.cv] paragraph 7, so the value of n might be different in each translation unit). However, it might be good to make it explicit that “a const object” is not intended to apply to a volatile-qualified object.

Other points that were raised during the discussion of this issue were that it would probably be better to rephrase “the value (but not the address) of the object is used” in terms of the odr-use of the object, as well as questioning why a const volatile variable implicitly has internal linkage.

Proposed resolution (October, 2012):

  1. Change 6.3 [basic.def.odr] paragraph 6 as follows:

    2. There can be more than one definition...

  2. Change 6.6 [basic.link] paragraph 3 as follows:

    3. A name having namespace scope (6.4.6 [basic.scope.namespace]) has internal linkage if it is the name of