[Bug c++/986] g++ misses warning for on temporary
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 ofhaving 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
--- 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 [EMAIL PROTECTED] 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=13531action=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
--- 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
--- 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
--- 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
--- 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
