[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Johannes Schaub from comment #7)
> Jonathan, unfortunately that code won't create and discard a temporary
> object,

Yes, you're right, there's no temporary so it's not relevant to this PR.

(Although your "whatever that means" assumes my example used std::lock_guard,
but if that was the case I'd have needed to use some template arguments.  Other
scoped-lock types are DefaultConstructible, e.g. std::unique_lock<T>)

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I still think it would be nice to get a warning for e.g.

   std::unique_lock<M>(m);

where "M m" is visible in an enclosing scope and would have been a viable
argument for another constructor, but that would be a different enhancement
request.

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[manu at gcc dot gnu.org]

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

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> ---
(In reply to Kaz Kylheku from comment #1)
> Created attachment 15798 [details]
> Implements -Wunused-objects warning for C++.

Patches need to be properly tested and submitted. See
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

The few people that have the power to approve patches are very busy and they
very rarely read bugzilla. Patches attached to bugzilla are usually understood
as proof-of-concept or work-in-progress, not actual submissions.
>From gcc-bugs-return-493114-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 23 13:54:44 2015
Return-Path: <gcc-bugs-return-493114-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 71208 invoked by alias); 23 Jul 2015 13:54:44 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 71132 invoked by uid 55); 23 Jul 2015 13:54:41 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/66908] Uninitialized variable when compiled with UBsan
Date: Thu, 23 Jul 2015 13:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66908-4-FZmjjVxEZn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66908-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66908-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02004.txt.bz2
Content-length: 651

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf908

--- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Thu Jul 23 13:54:06 2015
New Revision: 226110

URL: https://gcc.gnu.org/viewcvs?rev"6110&root=gcc&view=rev
Log:
        PR sanitizer/66908
        * c-ubsan.c: Include gimplify.h.
        (ubsan_instrument_division): Unshare OP0 and OP1.
        (ubsan_instrument_shift): Likewise.

        * c-c++-common/ubsan/pr66908.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/ubsan/pr66908.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-ubsan.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

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

--- Comment #11 from Kaz Kylheku <kkylheku at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to Kaz Kylheku from comment #1)
> > Created attachment 15798 [details]
> > Implements -Wunused-objects warning for C++.
> 
> Patches need to be properly tested and submitted. See
> https://gcc.gnu.org/wiki/GettingStarted#Basics:
> _Contributing_to_GCC_in_10_easy_steps
> 
> The few people that have the power to approve patches are very busy and they
> very rarely read bugzilla.

The bug database has an "enhancement" type, so obviously, it is to be used for
submitting enhancements. Why would you duplicate effort by implementing a
different process for tracking submissions?

In June 2008, when I submitted this, here is how the above Wiki page looked:

https://gcc.gnu.org/wiki/GettingStarted?action=recall&rev=19

There is no mention of any special process at that time.

Please "grandfather" old submissions that were posted to Bugzilla before the
special submission process was described in the Wiki.

>Patches attached to bugzilla are usually understood as proof-of-concept or work-in-progress, not actual submissions.

I deployed that change to large team of developers, and the toolchain with that
change went to customers also. The warning caught problems that were fixed and
didn't appear to break anything.

So yes, actual submission.

Today, I no longer care about upstreaming code to OSS projects because of prima
donna attitudes like this. It's just too much effort dealing with the barriers.

In my own projects, I accept good patches, even if they are written on a
grease-stained napkin.

If I lead by example, maybe others will follow.
>From gcc-bugs-return-493269-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 24 18:58:31 2015
Return-Path: <gcc-bugs-return-493269-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4705 invoked by alias); 24 Jul 2015 18:58:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3880 invoked by uid 48); 24 Jul 2015 18:58:27 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/55035] reload1.c:3766:41: error:=?UTF-8?Q? ‘orig_dup?=[0]=?UTF-8?Q?’ may be used uninitialized in this function ?=(for fr30, microblaze, moxie, rl78)
Date: Fri, 24 Jul 2015 18:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: build, diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc blocked
Message-ID: <bug-55035-4-jmkSZs8I1L@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55035-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55035-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02159.txt.bz2
Content-length: 1517

https://gcc.gnu.org/bugzilla/show_bug.cgi?idU035

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
             Blocks|                            |19794

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
Per this discussion:

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01996.html

It's believed the reduced testcase in c#5 is an invalid reduction.

A cursory review of the code in c#4 indicates that testcase is a valid
reduction.  We ought to be able to determine that the writes inside the two
inner loops do not clobber recog_data.n_dups and thus the first and last loops
iterate over the same space and every read of orig_dup[] in the last loop will
have had a value set in the first loop.

There's almost certainly a hideously complex missed jump threading opportunity
in here.  Conceptually it'd be exposed by duplicating the two inner loops, one
duplicate would be reached when n_dups is zero the other when n_dups is nonzero
after the first loop.   The first duplicate will bypass the last loop the
second duplicate would execute the final loop.  The net result of all that
copying and cfg transformations should in theory make the false positive
warning go away.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id\x19794
[Bug 19794] [meta-bug] Jump threading related bugs

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Kaz Kylheku from comment #11)
> The bug database has an "enhancement" type, so obviously, it is to be used
> for submitting enhancements.

No, it's for submitting enhancement *requests*, i.e. asking for or suggesting
enhancements.

Patches implementing those enhancements should be sent to the gcc-patches list,
like all patches.

> Why would you duplicate effort by implementing
> a different process for tracking submissions?

The process for submitting patches has always been to send them to the
gcc-patches list for review, why would you duplicate effort by asking reviewers
to also track patches in bugzilla?


> In June 2008, when I submitted this, here is how the above Wiki page looked:
> 
> https://gcc.gnu.org/wiki/GettingStarted?action=recall&rev=19
> 
> There is no mention of any special process at that time.

There is still no "special process", the process for submitting patches is
documented at https://gcc.gnu.org/contribute.html#patches and has always been
to send them to the gcc-patches mailing list. That wiki page says nothing about
attaching patches to bugzilla, but it does link to
https://gcc.gnu.org/contribute.html which describes the patch submission
process.

Of course we welcome suggestions for enhancements, especially if they come with
patches implementing the suggestion (that's the best kind! :-) but the process
for submitting patches is to send them to the mailing list (and there are also
legal prerequisites to be met, as described at the link above).

If you're not interested in submitting the patch through that process that's
unfortunate. Maybe someone else will be interested enough to do so on your
behalf, but that won't happen automatically. There is no way to go through
bugzilla and find patches posted here that were never sent via the correct
process (there are thousands of attachments in bugzilla, some are testcases,
some are patches that don't work, some are patches which were committed after
being sent to the mailing list, some are patches that were superseded by
improved patches sent to the list ... there is no way to automatically process
them and find the ones that were never dealt with).

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[manu at gcc dot gnu.org]

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

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Kaz Kylheku from comment #11)
> I deployed that change to large team of developers, and the toolchain with
> that change went to customers also. The warning caught problems that were
> fixed and didn't appear to break anything.

If the patch were to be upstreamed, it will be reviewed, regression tests would
be added to make sure it doesn't silently break, and your customers could
update to newer versions of GCC without losing the warning.

> Today, I no longer care about upstreaming code to OSS projects because of
> prima donna attitudes like this. It's just too much effort dealing with the
> barriers.
> 
> In my own projects, I accept good patches, even if they are written on a
> grease-stained napkin.

Perhaps your project is of a size that your team can do this. This is not the
case in large free-software projects, which all have much more pending work to
do than people to do it.

We already have trouble keeping up with the reviews of the patches people
submit following the proper procedure (just subscribe to gcc-patches and try to
read all that is going on there), which is supposed to favour quality and
future maintainability rather than quantity and quick development.

We do not have enough people with enough time to confirm all the bug reports
that are submitted (subscribe to gcc-bugs if you are brave enough). Thus, if
something is not critical, you do not actively pursue it and the active
developers have something more interesting or urgent to work on, your patch may
be ignored, even if you follow the proper procedures. See
https://gcc.gnu.org/wiki/Community

(The above is not a statement about whether the current procedures are ideal or
even beneficial. It is just a description of the status-quo, which seems to
work for the people who contribute patches every day to GCC, even if it doesn't
work so well for people that contribute only sporadically).
>From gcc-bugs-return-493288-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 24 22:52:24 2015
Return-Path: <gcc-bugs-return-493288-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 45008 invoked by alias); 24 Jul 2015 22:52:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 44973 invoked by uid 55); 24 Jul 2015 22:52:20 -0000
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/50584] No warning for passing small array to C99 static array declarator
Date: Fri, 24 Jul 2015 22:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50584-4-Qn2hqJ7Czm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50584-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50584-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02178.txt.bz2
Content-length: 1920

https://gcc.gnu.org/bugzilla/show_bug.cgi?idP584

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 3 Jul 2015, sergei.ivn+bugzilla at gmail dot com wrote:

> Some excerpts from the C11 standard:
>
> /-----
> If the keyword static also appears within the [ and ] of the array type
> derivation, then for each call to the function, the value of the corresponding
> actual argument shall provide access to the first element of an array with at
> least as many elements as specified by the size expression.
> \-----

This is in a Semantics section, not Constraints.

> I'm not sure about warnings (the meaning of the word "shall" is unclear for
> me), but IMO according to the standard null-pointers should issue an *error*.

"shall" is defined in clause 4, paragraph 2: 'If a "shall" or "shall not"
requirement that appears outside of a constraint or runtime-constraint is
violated, the behavior is undefined.'

In this case, the "shall" relates to a property of an execution of a
program, not a property of the program itself.  Thus, undefined behavior
only occurs on such an execution.  In particular, a program with such a
call inside if (0) - or in any code that the compiler cannot prove will
always be executed for all executions of the program - must *not* produce
an error at compile time.  To quote the response to DR#109, "A conforming
implementation must not fail to translate a strictly conforming program
simply because some possible execution of that program would result in
undefined behavior.".

Some such cases of runtime-undefined behavior get compiled into aborts,
but this is only valid if the abort only occurs when the undefined
function call would definitely be executed - not, for example, before the
evaluation of another argument to the function that might exit the program
or call longjmp (see previous bug fixes in this regard).

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |7.0
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
C++17 adds nodiscard attribute which can be placed on class/struct types,
functions, constructors and others and then you get a warning if you ignore the
value. In the case of struct/class types and constructors that will warn when a
temporary value is ignored. Exactly in the case you were asking for a warning.

Which was added to GCC by r7-377-gb632761d2c6a65 (and fixes afterwards).

So closing as fixed.

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

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

--- Comment #15 from Kaz Kylheku <kkylheku at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #13)
> (In reply to Kaz Kylheku from comment #11)
> > I deployed that change to large team of developers, and the toolchain with
> > that change went to customers also. The warning caught problems that were
> > fixed and didn't appear to break anything.
> 
> If the patch were to be upstreamed, it will be reviewed, regression tests
> would be added to make sure it doesn't silently break, and your customers
> could update to newer versions of GCC without losing the warning.

In April 2020 I created a patch for the GNU C Preprocessor, with documentation,
test cases and everything. I submitted it to the GCC Patches mailing list,
exactly as comments in this ticket from 2015 advised me I should have done for
this item back in 2008.

I received absolutely no replies; not even to reject the submission.

I "pinged" it a number of times, to no avail.

The four year anniversary is coming up; I'm going to ping again. Then if I'm
still ignored, one last time in April 2025.

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

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

--- Comment #16 from Kaz Kylheku <kkylheku at gmail dot com> ---
(In reply to Andrew Pinski from comment #14)
> C++17 adds nodiscard attribute which can be placed on class/struct types,
> functions, constructors and others and then you get a warning if you ignore
> the value. In the case of struct/class types and constructors that will warn
> when a temporary value is ignored. Exactly in the case you were asking for a
> warning.
> 
> Which was added to GCC by r7-377-gb632761d2c6a65 (and fixes afterwards).
> 
> So closing as fixed.

I'm afraid that this doesn't seem like a good resolution. The feature you are
referring to is opt-in, per class, whereas the proposed warning imposes the
behavior for every class.

This is a big difference.

The number of situations in which "classname(arg);" as an expression statement
with a discarded value is correct is pretty small. This is almost always going
to be a coding mistake. Where it isn't a coding mistake, the intent can be
indicated using "(void) classname(arg);".

The good news is that, at least it would seem that the implementation of the
warning can be piggybacked on the nodiscard attribute implementation. The
simplest possible requirement is that the option makes the compiler pretend
that the attribute has been asserted for every class. (I say tentatively,
without having studied the attribute's semantics in detail.)

nodiscard could be "stronger" in that if it is asserted, then even the cast to
(void) won't silence the diagnostic, so that it's still meaningful to use in
spite of the warning option.

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
No, the nodiscard warnings must be silenced with a cast to void. They can't be
"stronger" than that.

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Kaz Kylheku from comment #15)
> In April 2020 I created a patch for the GNU C Preprocessor, with
> documentation, test cases and everything. I submitted it to the GCC Patches
> mailing list, exactly as comments in this ticket from 2015 advised me I
> should have done for this item back in 2008.
> 
> I received absolutely no replies; not even to reject the submission.
> 
> I "pinged" it a number of times, to no avail.
> 
> The four year anniversary is coming up; I'm going to ping again. Then if I'm
> still ignored, one last time in April 2025.

This one?
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593460.html
Was there an earlier submission?

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

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

--- Comment #19 from Kaz Kylheku <kkylheku at gmail dot com> ---
(In reply to Jonathan Wakely from comment #18)
> Was there an earlier submission?

No there wasn't; that's my mistake in my comment.

[Bug c++/36587] New: Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

This patch implements a ``-Wunused-objects'' warning which is triggered if a
constructor is called, and the returned object is thrown away.

This can happen by accident when a declaration for an object accidentally omits
a name. For instance:

  {
    trace_class ("foo", ...);
    //         ^ missing name
  }

Whereas it is common for C++ function calls to discard returned objects,
discarding the result of an explicit constructor call is most likely a mistake.

I developed a patch against GCC 4.1.1 for this (because that's the compiler
currently used by my organization). The patch doesn't include a documentation
update, just code.


-- 
           Summary: Feature: add warning for constructor call with discarded
                    return.
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kkylheku at gmail dot com


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

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

------- Comment #1 from kkylheku at gmail dot com  2008-06-20 19:23 -------
Created an attachment (id=15798)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15798&action=view)
Implements -Wunused-objects warning for C++.


-- 


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

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

------- Comment #2 from kkylheku at gmail dot com  2008-06-20 20:26 -------
I should add that this is different from -Wunused-value, because I want this
warning emitted even if the constructor (or its corresponding destructor) have
side effects.


-- 


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

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[redi at gcc dot gnu dot org]

------- Comment #3 from redi at gcc dot gnu dot org  2009-12-11 00:37 -------
This would have prevented bugs I've dealt with where critical sections where
not protected:
{
  lock_guard (mutex);
  // mutex NOT locked here!
}

But I'm not convinced that doing this is always a mistake. Would the warning be
suppressed by casting to void?

  (void) TypeWithSideEffectsInCtor(x);


-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redi at gcc dot gnu dot org


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

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

------- Comment #4 from kkylheku at gmail dot com  2009-12-11 02:34 -------
(In reply to comment #3)
> This would have prevented bugs I've dealt with where critical sections where
> not protected:
> {
>   lock_guard (mutex);
>   // mutex NOT locked here!
> }
> But I'm not convinced that doing this is always a mistake.

Since we don't care about the object, we must care about the constructor side
effect. I seem to be under the impression that ISO C++ allows the construction
of temporary objects to be optimized away---even if there are side effects in
the constructor or destructor! Therefore, it's hard to see a valid use case for
this.

 Would the warning be
> suppressed by casting to void?
>   (void) TypeWithSideEffectsInCtor(x);

Not as implemented, I am afraid. The diagnostic is still produced that the
object is discarded. This is can be regarded as a flaw; something explicitly
requested by a cast should not be diagnosed.


-- 


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

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[jwakely dot gcc at gmail dot com]

------- Comment #5 from jwakely dot gcc at gmail dot com  2009-12-11 10:39 -------
(In reply to comment #4)
> > But I'm not convinced that doing this is always a mistake.
> 
> Since we don't care about the object, we must care about the constructor side
> effect. I seem to be under the impression that ISO C++ allows the construction
> of temporary objects to be optimized away---even if there are side effects in
> the constructor or destructor! Therefore, it's hard to see a valid use case for
> this.

Certain temporaries (such as those created during copying or reference binding)
can be optimised away, I don't think it's true of temporaries created
explicitly like this.  e.g. I think this should work:

std::ofstream("lockfile");  // creates ./lockfile if it doesn't exist

(assuming write permission in the directory, and ignoring races and other
reasons it might be a bad idea)


-- 


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

[Bug c++/36587] Feature: add warning for constructor call with discarded return.

[kkylheku at gmail dot com]

------- Comment #6 from kkylheku at gmail dot com  2009-12-11 11:57 -------
(In reply to comment #5)
> (In reply to comment #4)
> > > But I'm not convinced that doing this is always a mistake.
> > 
> > Since we don't care about the object, we must care about the constructor side
> > effect. I seem to be under the impression that ISO C++ allows the construction
> > of temporary objects to be optimized away---even if there are side effects in
> > the constructor or destructor! Therefore, it's hard to see a valid use case for
> > this.
> Certain temporaries (such as those created during copying or reference binding)
> can be optimised away, I don't think it's true of temporaries created
> explicitly like this.

I've gone over the relevant 14882:2003 sections and have come to the same
conclusion.


-- 


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