[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[adam.rak at streamnovation dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Ádám Rák <adam.rak at streamnovation dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adam.rak at streamnovation
                   |                            |dot com

--- Comment #8 from Ádám Rák <adam.rak at streamnovation dot com> 2010-11-26 00:30:17 UTC ---
in g++-4.6 (and maybe all before) this bug can be even more troublesome:
struct AA
{
 int &a;
 AA() : a(a)
 {
 }
};

int main()
{
        AA aa;
        cout << &aa.a << endl;
        return 0;
}

compiled without a warning even with
g++ main.cpp -O3 -Wall -pedantic -Wextra -Winit-self -Wuninitialized

And in -O0 it prints some address, probably the address of the reference as
suggested before. But in -O1..3 it prints a 0, which means we made an
nullreference. 

The practical problem is that because of this, the code can be easily messed up
like this:

class AA
{
...int &aaa;

   AA(int& aaaa) : aaa(aaa) {...

A single typo and the compiled does really strange things, the segfault is best
case, sometimes the reference points a valid address. It is very hard to debug
too. And when the programmer checks the code he/she can naively think that the
compiler should check it, so "why bother checking whether they are spelled
exactly the same?"

The old testcase was a bit harder to do accidentally, this one can happen more
easily. A self-init warning might enough to clue the programmer if this
happens. An error would be better if we are sure this is invalid.

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-11-26 10:59:24 UTC ---
(In reply to comment #2)
> int &a = a;
> i don't believe this is valid code.  i believe g++ should reject the code.

I'm not convinced the compiler must reject it. EDG accepts it too.

> various comp.std.c++ people agree with me.

Working link to the thread:
http://groups.google.com/group/comp.std.c++/browse_thread/thread/fb732bbcd0fecec5/4e04facc65ebf2f5

> 8.3.2/4 states "[...] A reference shall be initialized to refer to a valid
> object or function."
>
> surely a (the right-hand-side) is not a valid object or function since it has
> not been initialised, so the code is ill-formed.

Right, but consider:

inline int& f(int& i) { return i; }

int& i = f(i);

And then consider if f(int&) is not inline and is defined in another
translation unit.  The compiler can warn that f(i) uses an uninitialized
variable but can't know that the initializer for i is invalid, because maybe
f() does return a reference to a valid object.

(In reply to comment #8)
> in g++-4.6 (and maybe all before) this bug can be even more troublesome:
> struct AA
> {
>  int &a;
>  AA() : a(a)
>  {
>  }
> };
> 
> int main()
> {
>         AA aa;
>         cout << &aa.a << endl;
>         return 0;
> }
> 
> compiled without a warning even with

That's simply because we don't do uninitialized warnings for data members,
that's a separate bug.

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-11-26 11:11:29 UTC ---
(In reply to comment #9)
> (In reply to comment #2)
> > int &a = a;
> > i don't believe this is valid code.  i believe g++ should reject the code.
> 
> I'm not convinced the compiler must reject it. EDG accepts it too.

Without warning? What about clang 2.8?

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-11-26 11:25:30 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #2)
> > > int &a = a;
> > > i don't believe this is valid code.  i believe g++ should reject the code.
> > 
> > I'm not convinced the compiler must reject it. EDG accepts it too.
> 
> Without warning? What about clang 2.8?

Yes, without warning (G++ at least warns)
I don't know about clang

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[pentek.imre at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

--- Comment #12 from Imre Pentek <pentek.imre at gmail dot com> 2010-11-26 17:18:26 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > (In reply to comment #2)
> > > > int &a = a;
> > > > i don't believe this is valid code.  i believe g++ should reject the code.
> > > 
> > > I'm not convinced the compiler must reject it. EDG accepts it too.
> > 
> > Without warning? What about clang 2.8?
> 
> Yes, without warning (G++ at least warns)
> I don't know about clang

This code is as valid as unset references are valid. The standards doesn't
allow 'unset' or 'extremal' references. In this way there's no point to query
the reference from a yet-unset reference, as there's no such a state as unset
reference. If you somehow manage to query the reference from an unset reference
you actually navigated your compiler to a state which doesn't even exist. It's
like division by zero to be accepted without any (runtime/compiletime) error
messages/crashes. Briefly, I consider this code as invalid, as it generates a
state which is invalid, and has no semantic meaning, and doesn't really exist.

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-11-26 17:37:33 UTC ---
There are lots of ways to put your program into an invalid state.

Of course there's "no point" to doing it, and noone's asking for the code to
*work*

The question is whether the compiler is expected to diagnose the code and
reject it.

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[adam.rak at streamnovation dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

--- Comment #14 from Ádám Rák <adam.rak at streamnovation dot com> 2010-11-27 13:45:03 UTC ---
(In reply to comment #13)
> There are lots of ways to put your program into an invalid state.
> 
> Of course there's "no point" to doing it, and noone's asking for the code to
> *work*
> 
> The question is whether the compiler is expected to diagnose the code and
> reject it.

If we cannot decide, we should at least give a verbose warning, included into
-Wall.

[Bug c++/18635] use of uninitialised reference accepted in C++ front end

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-22 18:40:26 UTC ---
(In reply to comment #14)
> If we cannot decide, we should at least give a verbose warning, included into
> -Wall.

There's already a warning for the original testcase, the one in comment 8 is
covered by PR 18016 and I have a patch for that

[Bug c++/18635] [DR 504] use of uninitialised reference accepted in C++ front end

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED
            Summary|use of uninitialised        |[DR 504] use of
                   |reference accepted in C++   |uninitialised reference
                   |front end                   |accepted in C++ front end

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-27 11:43:43 UTC ---
This is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3293.html#504
which is Open, so I'm suspending this. If/when that gets resolved we can
revisit this PR.

I think SUSPENDED rather than INVALID is being generous, as G++ is completely
correct to accept the code, and follows the committee's intentions:
"Implementations can warn about such constructs, and the resolution for issue
453 makes executing such code undefined behavior; that seemed to address the
situation adequately."

[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #18 from Martin Sebor <msebor at gcc dot gnu.org> ---
What is this a request for?

GCC 11 issues the warnings below, as well as for most of the test cases here. 
Since (I assume most of us agree) rejecting the code would not be
correct/conforming, is there something else to enhance?   (There are
bugs/limitations in -Wuninitialized that prevent diagnosing some similar cases
but I'd expect to track those as bugs separately from this request.)

$ cat t.C && gcc -S -Wall t.C
const int* fcp (const int *);

void gcp ()
{
  const int *p = fcp (p);    // -Wuninitialized
}

const int& fcr (const int &);

void gcr ()
{
  const int &i = fcr (i);    // -Wuninitialized
}

int& fr (int &);

void gr ()
{
  int &r = fr (r);           // -Wuninitialized
}

t.C: In function ‘void gcp()’:
t.C:5:22: warning: ‘p’ is used uninitialized [-Wuninitialized]
    5 |   const int *p = fcp (p);    // -Wuninitialized
      |                  ~~~~^~~
t.C:5:14: note: ‘p’ was declared here
    5 |   const int *p = fcp (p);    // -Wuninitialized
      |              ^
t.C: In function ‘void gcr()’:
t.C:12:22: warning: ‘i’ is used uninitialized [-Wuninitialized]
   12 |   const int &i = fcr (i);    // -Wuninitialized
      |                  ~~~~^~~
t.C:12:14: note: ‘i’ was declared here
   12 |   const int &i = fcr (i);    // -Wuninitialized
      |              ^
t.C: In function ‘void gr()’:
t.C:19:15: warning: ‘r’ is used uninitialized [-Wuninitialized]
   19 |   int &r = fr (r);           // -Wuninitialized
      |            ~~~^~~
t.C:19:8: note: ‘r’ was declared here
   19 |   int &r = fr (r);           // -Wuninitialized
      |        ^

[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://www.open-std.org/jtc
                   |                            |1/sc22/wg21/docs/papers/201
                   |                            |1/n3293.html#504

--- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #18)
> What is this a request for?

What GCC should do depends on the DR which is still open. Until the DR is
resolved one way or another, this PR should stay suspended.

[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|24639                       |

--- Comment #20 from Martin Sebor <msebor at gcc dot gnu.org> ---
So the open question is whether to issue an error in the front end rather than
a warning in the middle end.  Let me remove the dependency on -Wuninitialized
then since there's nothing to do there.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, the core issue is still active, so currently compilers are required to
accept the code rather than reject it as ill-formed. If that changes, we can
un-suspend this.

[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #22 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Now closed as NAD: https://cplusplus.github.io/CWG/issues/504.html