This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 112e. See for the official list.


434. Unclear suppression of standard conversions while binding reference to lvalue

Section: 9.4.4  [dcl.init.ref]     Status: NAD     Submitter: Bronek Kozicki     Date: 14 September 2003

In section 9.4.4 [dcl.init.ref], paragraph 5, there is following note:

Note: the usual lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not needed, and therefore are suppressed, when such direct bindings to lvalues are done.

I believe that this note is misleading. There should be either:

The problem:

  1. under current wording it's unclear if following code is legal, or not:
    int main()
      const int ci = 10;
      int * pi = NULL;
      const int * & rpci = pi;
      rpci = &ci;
      *pi = 12; // circumvent constness of "ci"
  2. it is also unclear what behaviour should following program expose:
    int main()
      int * pi = NULL;
      const int * const & rcpci = pi; // 1
      int i = 0;
      pi = &i; // 2
      if (pi == rcpci)
        std::cout << "bound to lvalue" << std::endl;
        std::cout << "bound to temporary rvalue" << std::endl;

There has been discussion on this issue on comp.lang.c++.moderated month ago, see and there seems to be some confusion about it. I understand that note is not normative, but apparently even some compiler writers are misled (try above code snippets on few different compilers, and using different compilation options - notably GCC 3.2.3 with -Wall -pedantic), thus it should be cleared up.

My proposal is to change wording of discussed note to:

Note: result of every standard conversion is never an lvalue, and therefore all standard conversions (clause 4) are suppressed, when such direct bindings to lvalues are done.

Rationale (April, 2005):

As acknowledged in the description of the issue, the referenced text is only a note and has no normative impact. Furthermore, the examples cited do not involve the conversions mentioned in the note, and the normative text is already sufficiently clear that the types in the examples are not reference-compatible.