[Bug c++/986] g++ misses warning for & on temporary

[Bug c++/986] g++ misses warning for & on temporary

[bangerth at dealii dot org]

------- Comment #9 from bangerth at dealii dot org  2006-10-26 06:35 -------
*** Bug 29593 has been marked as a duplicate of this bug. ***


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris at bubblescope dot net


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

[Bug c++/986] g++ misses warning for & on temporary

[bangerth at dealii dot org]

------- Comment #10 from bangerth at dealii dot org  2007-05-02 22:56 -------
*** Bug 31788 has been marked as a duplicate of this bug. ***


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkruger at stevens dot edu


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

[Bug c++/986] g++ misses warning for & on temporary

[bangerth at dealii dot org]

------- Comment #13 from bangerth at dealii dot org  2007-05-08 15:34 -------
(In reply to comment #12)
> The summary says "g++ misses warning for & on temporary". But something that is
> always an error can be called a warning?

The point is that the standard doesn't call it an error, but undefined
behavior. It's perfectly legal to keep a reference to a temporary, it
may just not yield the result you had hoped for.

W.


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[raf2 at msux dot cjb dot net]

------- Comment #14 from raf2 at msux dot cjb dot net  2007-05-08 17:18 -------
I first was hit by an error using MinGW... when I compiled and executed the
first attached file, it wrote:

        John drives a: "bus"
        Otto drives a: "bus"

Which was wrong, I reported the bug and a guy from MinGW kindly explained that
if it worked then that would be purely by accident and added:
" When you declare the argument without '&' then it will make a temporary copy
of the Automobile object on the stack, but it is wrong to store a reference to
a temporary object because it will be invalid after the constructor returns.". 


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[raf2 at msux dot cjb dot net]

------- Comment #15 from raf2 at msux dot cjb dot net  2007-05-08 17:22 -------
Created an attachment (id=13531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13531&action=view)
File with wrong code that leads to an unexpected result


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[bangerth at dealii dot org]

------- Comment #16 from bangerth at dealii dot org  2007-05-08 17:25 -------
(In reply to comment #14)
> Which was wrong, I reported the bug and a guy from MinGW kindly explained that
> if it worked then that would be purely by accident and added:
> " When you declare the argument without '&' then it will make a temporary copy
> of the Automobile object on the stack, but it is wrong to store a reference to
> a temporary object because it will be invalid after the constructor returns.". 

You misunderstand my point: the international C++ standard quite clearly
specifies under what circumstances a program is what it calls "ill-formed"
and when a compiler has to issue an error. Taking the address of a temporary
is completely valid according to this standard (i.e. it conforms to the
*syntax*
of the C++ language), and consequently a compiler can't issue an error.

The fact that the program does something you may not expect, i.e. that the
*semantics* are not what you want, is an entirely different matter. In this
case, the C++ standard says that the behavior of your program is undefined.
Compilers may warn about this, but they may not issue an error.

W.


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[raf2 at msux dot cjb dot net]

------- Comment #17 from raf2 at msux dot cjb dot net  2007-05-09 16:27 -------
> Compilers may warn about this, but they may not issue an error.
Let's see what has to say the freely available Borland C++ 5.5.1 for Windows.
Yes, it wisely stops people from compiling the attached "main.cpp":

Error E2359 main.cpp 23: Reference member 'Driver::what_drives' initialized
with a non-reference parameter in function Driver::Driver(Automobile)

Are comitee decisions (right or wrong) more important than  consequences for
people? So Borland protects people from undefined behaviours when they can, and
I wonder, isn't what most people need? isn't what most people want? 


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[bangerth at dealii dot org]

------- Comment #18 from bangerth at dealii dot org  2007-05-09 16:39 -------
(In reply to comment #17)
> Are comitee decisions (right or wrong) more important than  consequences for
> people? So Borland protects people from undefined behaviours when they can, and
> I wonder, isn't what most people need? isn't what most people want? 

You probably won't get very far by insulting people. Let it be said that the
committee's wise decision to not require an error also helps me in this
circumstance: if you go back to the example I gave in the very first comment
of this PR, then yes, using an object of type 'Y' is probably going to lead
to nothing good. On the other hand, if I never use an object of type 'Y',
then the program may look dubious, but bad nothing is going to happen. 

In other words, Borland's compiler is going to prevent me from compiling
a program that is perfectly fine, is going to do everything I want, and is
going to do that reliably. Is that what you want?

W.


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[chris at bubblescope dot net]

------- Comment #19 from chris at bubblescope dot net  2007-05-09 17:05 -------
while I agree we shouldn't produce an error here, personally I'm highly
unconvinced by your argument. If I had some code which if called would always
lead to undefined behaviour, but never called it, I would still want to be
told. By the same argument, why bother type-checking functions if we can prove
they are never called?


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[raf2 at msux dot cjb dot net]

------- Comment #20 from raf2 at msux dot cjb dot net  2007-05-14 09:30 -------
We have talked about the undefined behaviour of   having references to objects
that have been destroyed.

Can someone provide a program with that undefined behaviour that could not be
considered an error?


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[bangerth at dealii dot org]

------- Comment #21 from bangerth at dealii dot org  2007-05-14 17:50 -------
This is getting completely off-topic, so here's my last post:

(In reply to comment #20)
> Can someone provide a program with that undefined behaviour that could not be
> considered an error?

As long as you don't touch the undefined value, everything's ok:

-----------------
struct X {   X (int);    };

struct Y {
    Y ();
    int do_something () { return 1; }
    const X &x;   // note the ampersand
};

Y::Y () : x(1)  {};  // creates a temporary and stores address

int main () {
  Y y;
  return y.do_something();
}
----------------------


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[raf2 at msux dot cjb dot net]

------- Comment #22 from raf2 at msux dot cjb dot net  2007-05-16 08:50 -------
Mmm... maybe I haven't explained correctly.

If you contract someone to build stairs and later he says: "As long as you
don't touch this step, everything's ok" you tell him some nasty things.

The users of our g++ programs, our boss, will tell us the same nasty things if
they know of equivalent features in our programs. 

That's the point of having the compiler stopping compilations when (for
example) it detects a reference to an object that has been destroyed. 

Unless someone has a useful employ of    having references to objects that have
been destroyed, that is why a sample is asked.


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[manu at gcc dot gnu dot org]

------- Comment #23 from manu at gcc dot gnu dot org  2007-05-16 14:03 -------
Hi Naimu, I am not speaking in the name of the GCC community but I would like
to prevent your frustration. You exposed your point clearly. People that have a
deep knowledge of C++ and g++ don't agree with you. Repeating your point again
is not doing any good. 

You may go to gcc@gcc.gnu.org and expose your point to a broader audience. I
think this is going to be unsuccessful for a fundamental and a practical
reason. The fundamental reason is that the standard doesn't call this an error.
And GCC implements that C++ standard. It is the same case as with uninitialized
variables. 

The practical reason is that converting a warning into an error is trivial (or
viceversa) but implementing the warning/error in the first place is not. So
people are going to say "Come back when it is implemented and we will discuss
then whether it should be a warning or an error".


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[paolo dot carlini at oracle dot com]

------- Comment #24 from paolo dot carlini at oracle dot com  2009-08-05 12:34 -------
*** Bug 40970 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |devh at stuffit dot at


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

[Bug c++/986] g++ misses warning for & on temporary

[manu at gcc dot gnu dot org]

------- Comment #25 from manu at gcc dot gnu dot org  2009-08-05 13:21 -------
If anyone has any hint on where this could be caught, suggestions are welcome.

The explanation of Alexandre Oliva in comment #8 is totally obscure to me and
perhaps outdated given the age of this PR.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-12-11 21:50:19         |2009-08-05 13:21:18
               date|                            |


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

[Bug c++/986] g++ misses warning for & on temporary

[driscoll at cs dot wisc dot edu]

------- Comment #26 from driscoll at cs dot wisc dot edu  2010-08-27 22:02 -------
I was surprised to see this is not caught by a warning as well. (The discussion
of whether it should be an error is silly; it pretty clearly shouldn't be.
There's -Werror if you disagree.)

Motivation: This surfaced in the code I'm working on as it has several similar
functions that return std::sets of objects. I changed several of them to return
by const-reference for efficiency purposes, but not all of them could be
modified such. I then changed call sites so that the return was stored in a
const-reference instead of copied. I expected the compiler to be able to catch
any mismatches (storing the by-value return in a reference), but when I ran a
test to see if it would, there was no warning.

Examples:

This first one is inspired by the code I was working on:
  int retByVal() {
      return 5;
  }
  int foo() {
      int const & v = retByVal();  // no warning
      return v;                    // no warning
  }
but you don't even need to get that complicated. The following illustrates as
well:
  int foo() {
      int const & x = 4;  // no warning
      return x;           // no warning
  }


Comparison of compilers:
- GCC fails to warn for either examples:
    - 3.3.3, 3.4.6 (-Wall -W)
    - 4.1.2, 4.5.1 (-Wall -Wextra)
- MSVC fails to warn for either of these examples
    - 2005, 2008 (level 4)
    - 2010 (all warnings, /Wall)
- The EDG front end warns if remarks are on:
    - Intel CC (10.1 -Wall),  *does* warn about these examples. E.g.:
        remark #383: value copied to temporary, reference to temporary used
        int const & v = retByVal();
    - Comeau (with -r) warns


I haven't lost debugging time to this or anything like that, but I am a bit
disappointed and surprised to see that neither MSVC nor GCC warns for this
almost-certain error and thought I'd contribute in the hopes that another
person running across it might inspire someone to fix it.


-- 

driscoll at cs dot wisc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |driscoll at cs dot wisc dot
                   |                            |edu


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

[Bug c++/986] g++ misses warning for & on temporary

[pinskia at gcc dot gnu dot org]

------- Comment #27 from pinskia at gcc dot gnu dot org  2010-08-27 22:21 -------
>This first one is inspired by the code I was working on:

Your two functions are well defined as the scope of the temp is only lost after
going out of scope.  So there is no references to a temp escaping unlike the
original example.


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[driscoll at cs dot wisc dot edu]

------- Comment #28 from driscoll at cs dot wisc dot edu  2010-08-27 22:53 -------
> Your two functions are well defined as the scope of the temp is only lost
> after going out of scope.

I see "A reference is bound to a temporary object: the temporary object is
destroyed at the end of the reference's lifetime" at
<http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/cplr382.htm>
(as well as 12.2 para 5 in the standard) now... that's something I totally did
not know.

Thanks, and sorry for the spam.


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[redi at gcc dot gnu dot org]

------- Comment #29 from redi at gcc dot gnu dot org  2010-08-28 14:39 -------
that's why EDG only gives a "remark" not a warning


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[redi at gcc dot gnu dot org]

------- Comment #30 from redi at gcc dot gnu dot org  2010-08-28 14:42 -------
Can we change the summary to mention references?  It looks to me as though it's
talking about the address-of operator.


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-16 01:47 -------
Uh? I never saw this bug before. Clearly there is nothing wrong in the code, as 
the temporary is *bound* to the constant reference, so that its lifetime 
extends to Y's liftime.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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

[Bug c++/986] g++ misses warning for & on temporary

[joerg dot richter at pdv-fs dot de]

------- Additional Comments From joerg dot richter at pdv-fs dot de  2004-06-16 08:31 -------
The lifetime of the temporary is not expanded to Y's lifetime.

12.2/5

"A temporary bound to a reference member in a constructor's ctor-initializer 
persists until the constructor exits."

So acually there is a dangling reference after the constructor was called. 
I think a warning in this place would be fine.


-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-16 10:20 -------
Ah thank you. It seemed odd to me nobody had noticed this...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


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

[Bug c++/986] g++ misses warning for & on temporary

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-06-16 13:14 -------
Right, the temporary most definitely can't live until the end of 
the object, since if this were so the compiler would have to create 
a list of temporaries generated during construction, and delete them 
during destruction of the object. We know that this doesn't happen. 
 
W. 

-- 


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

[Bug c++/986] g++ misses warning for & on temporary

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW


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

[Bug c++/986] g++ misses warning for & on temporary

[aoliva at gcc dot gnu dot org]

------- Additional Comments From aoliva at gcc dot gnu dot org  2005-02-16 17:27 -------
Getting a warning to be issued is easy: initialize_ref may print it if it finds
that the call to convert_like will create a temporary, testing
conv->need_temporary_p.  However, this would trigger warnings for binding
default args to reference parameters as well.  If we get fndecl passed down from
convert_for_initialization, and test for !fndecl as well, you get the correct
warnings, but you still don't get correct behavior: the dtor for the temporary
that appears in the mem-initializer-list should be called at the end of the
ctor, i.e., after the body of the ctor.  Currently, it's called too early. 
Reworking the reference initialization code to create a cleanup for the ctor
body and pass that down shouldn't be too hard, but I've already used up the time
slot I'd allocated for this bug.  As for the life of a default arg, it does
extend past the actual function call, which is correct, but it would probably be
a plus to get it handled in the same way as other reference binding to args.

-- 


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