Title
const volatile variables and the one-definition rule
Status
cd3
Section
6.3 [basic.def.odr]
Submitter
Richard Smith

Created on 2012-06-18.00:00:00 last changed 123 months ago

Messages

Date: 2013-04-15.00:00:00

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

Date: 2012-10-15.00:00:00

Proposed resolution (October, 2012):

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

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

    • ...

    • 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 non-volatile 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 not odr-used, and the object has the same value in all definitions of D; and

    • ...

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

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

    • a variable, function or function template that is explicitly declared static; or,

    • a non-volatile variable that is explicitly declared const or constexpr and neither explicitly declared extern nor previously declared to have external linkage; or

    • a data member of an anonymous union.

Date: 2022-09-25.18:08:42

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.

History
Date User Action Args
2014-03-03 00:00:00adminsetstatus: drwp -> cd3
2013-10-14 00:00:00adminsetstatus: dr -> drwp
2013-05-03 00:00:00adminsetmessages: + msg4368
2013-05-03 00:00:00adminsetstatus: ready -> dr
2012-11-03 00:00:00adminsetmessages: + msg4043
2012-11-03 00:00:00adminsetstatus: open -> ready
2012-06-18 00:00:00admincreate