public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect
@ 2014-05-06 18:05 peter_e at gmx dot net
  2014-05-06 18:29 ` [Bug c/61081] " mpolacek at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 10+ messages in thread
From: peter_e at gmx dot net @ 2014-05-06 18:05 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 61081
           Summary: excessive warnings: right-hand operand of comma
                    expression has no effect
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: peter_e at gmx dot net

OS X has the following system header definitions:

#define sigaddset(set, signo)   (*(set) |= __sigbits(signo), 0)
#define sigdelset(set, signo)   (*(set) &= ~__sigbits(signo), 0)
#define sigismember(set, signo) ((*(set) & __sigbits(signo)) != 0)
#define sigemptyset(set)    (*(set) = 0, 0)
#define sigfillset(set)     (*(set) = ~(sigset_t)0, 0)

gcc 4.9 with -Wall with complain about any use thereof with the newly
introduced

    right-hand operand of comma expression has no effect

I think the above programming patterns is common and legitimate in macros
(search engines bring up similar cases) and without an elegant alternative. 
Warning about the right-hand expression having no effect is incorrect because
it supplies the return value of the expression (unlike the left-hand side).

I suggest that this warning be removed, or at least moved away from -Wall.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
@ 2014-05-06 18:29 ` mpolacek at gcc dot gnu.org
  2014-05-06 18:33 ` peter_e at gmx dot net
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 10+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-05-06 18:29 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Can't you just cast the RHS to void?


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
  2014-05-06 18:29 ` [Bug c/61081] " mpolacek at gcc dot gnu.org
@ 2014-05-06 18:33 ` peter_e at gmx dot net
  2014-05-06 19:03   ` Marek Polacek
  2014-05-06 19:03 ` polacek at redhat dot com
                   ` (5 subsequent siblings)
  7 siblings, 1 reply; 10+ messages in thread
From: peter_e at gmx dot net @ 2014-05-06 18:33 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Peter Eisentraut <peter_e at gmx dot net> ---
No, these "functions" need to have a usable return value, because someone could
write

if (!sigemptyset(...))
    weirderror();


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
  2014-05-06 18:29 ` [Bug c/61081] " mpolacek at gcc dot gnu.org
  2014-05-06 18:33 ` peter_e at gmx dot net
@ 2014-05-06 19:03 ` polacek at redhat dot com
  2014-05-08  0:17 ` peter_e at gmx dot net
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 10+ messages in thread
From: polacek at redhat dot com @ 2014-05-06 19:03 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Marek Polacek <polacek at redhat dot com> ---
On Tue, May 06, 2014 at 06:33:03PM +0000, peter_e at gmx dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081
> 
> --- Comment #2 from Peter Eisentraut <peter_e at gmx dot net> ---
> No, these "functions" need to have a usable return value, because someone could
> write
> 
> if (!sigemptyset(...))
>     weirderror();

So would the following work for you?
#define sigemptyset(set) (__extension__ ({ *(set) = 0; 0; }))


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:33 ` peter_e at gmx dot net
@ 2014-05-06 19:03   ` Marek Polacek
  0 siblings, 0 replies; 10+ messages in thread
From: Marek Polacek @ 2014-05-06 19:03 UTC (permalink / raw)
  To: peter_e at gmx dot net; +Cc: gcc-bugs

On Tue, May 06, 2014 at 06:33:03PM +0000, peter_e at gmx dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081
> 
> --- Comment #2 from Peter Eisentraut <peter_e at gmx dot net> ---
> No, these "functions" need to have a usable return value, because someone could
> write
> 
> if (!sigemptyset(...))
>     weirderror();

So would the following work for you?
#define sigemptyset(set) (__extension__ ({ *(set) = 0; 0; }))


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
                   ` (2 preceding siblings ...)
  2014-05-06 19:03 ` polacek at redhat dot com
@ 2014-05-08  0:17 ` peter_e at gmx dot net
  2014-05-16 20:19 ` peter_e at gmx dot net
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 10+ messages in thread
From: peter_e at gmx dot net @ 2014-05-08  0:17 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Peter Eisentraut <peter_e at gmx dot net> ---
Not really, because this code is in header files not under my control, and
those header files should presumably work with a variety of C compilers and
shouldn't need to rely on GCC extensions.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
                   ` (3 preceding siblings ...)
  2014-05-08  0:17 ` peter_e at gmx dot net
@ 2014-05-16 20:19 ` peter_e at gmx dot net
  2014-05-23 15:39 ` mpolacek at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 10+ messages in thread
From: peter_e at gmx dot net @ 2014-05-16 20:19 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Peter Eisentraut <peter_e at gmx dot net> ---
This particular case is in system headers, but there are other cases that are
not, so this isn't going to help in general.

I think this is a legitimate way to write a function-like macro that has a
side-effect and a return value, and the warning is bogus.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
                   ` (4 preceding siblings ...)
  2014-05-16 20:19 ` peter_e at gmx dot net
@ 2014-05-23 15:39 ` mpolacek at gcc dot gnu.org
  2014-06-25 19:16 ` manu at gcc dot gnu.org
  2015-02-10 21:01 ` [Bug target/61081] " pinskia at gcc dot gnu.org
  7 siblings, 0 replies; 10+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-05-23 15:39 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Can we settle on just disabling the warning for system headers?  Those are kind
of out of control, but otherwise if you really want it, use ({ }) or make it a
static inline function (as glibc/kernel).  For static inlines there is no
performance penalty.
Note that the C++ FE has this warning for much more longer than the C FE,
completely removing it doesn't seem desirable to me.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
                   ` (5 preceding siblings ...)
  2014-05-23 15:39 ` mpolacek at gcc dot gnu.org
@ 2014-06-25 19:16 ` manu at gcc dot gnu.org
  2015-02-10 21:01 ` [Bug target/61081] " pinskia at gcc dot gnu.org
  7 siblings, 0 replies; 10+ messages in thread
From: manu at gcc dot gnu.org @ 2014-06-25 19:16 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Peter Eisentraut from comment #2)
> No, these "functions" need to have a usable return value, because someone
> could write
> 
> if (!sigemptyset(...))
>     weirderror();

Note that just using:

(void) sigemptyset();

silences the warning in those cases where you want to ignore the return value,
which could be useful while someone comes up with a patch for a more permanent
fix.

Or you can use -Wno-unused-value for now.
>From gcc-bugs-return-454950-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 25 19:24:41 2014
Return-Path: <gcc-bugs-return-454950-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14248 invoked by alias); 25 Jun 2014 19:24:40 -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 14168 invoked by uid 48); 25 Jun 2014 19:24:32 -0000
From: "arthur.j.odwyer at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/61613] New: ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name
Date: Wed, 25 Jun 2014 19:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.6.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: arthur.j.odwyer at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61613-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: 2014-06/txt/msg02032.txt.bz2
Content-length: 2629

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

            Bug ID: 61613
           Summary: ,##__VA_ARGS__ fails to expand the first variadic
                    argument if it is a macro-name
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arthur.j.odwyer at gmail dot com

The following program uses the ",##__VA_ARGS__" token-pasting extension
described here: https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

cat >test.cc <<EOF
#include <stdio.h>
const char* print(int, const char* s) { puts(s); return "result"; }
#define print(x,...) (print(1,"macro"),print(1, ##__VA_ARGS__))
int main() {
    print(1,print(1,"world"));
}
EOF
g++ test.cc
./a.out


This program prints "macro world result", indicating that the second (inner)
occurrence of `print` on line 5 was blue-painted before it was expanded.

If you remove the "##" from the definition of the `print` macro, the new
program prints "macro world result result", indicating that both occurrences of
`print` on line 5 have been expanded.

I believe that the latter behavior is correct and the former behavior is WRONG;
I cannot convince myself that the presence of ,## on line 3 should have any
effect.

I think maybe what's happening is that the preprocessor is **actually**
token-pasting `,` and `print` to get the pp-token `,print` which is not a
macro-name so it doesn't get expanded; but in that case, I would expect a
syntax error because `,print` is not a valid pp-token.  Silently blue-painting
the first token of every variadic macro argument list is a big misfeature.



This bug was discovered while testing an "on-scope-exit-do" macro:

    {
        OnScopeExitDo(baz());
        OnScopeExitDo(bar());
        foo();
    }

worked as expected, but

    {
        OnScopeExitDo(OnScopeExitDo(baz()); bar());
        foo();
    }

failed to compile, complaining that it couldn't find any function definition
for the inner, incorrectly-blue-painted `OnScopeExitDo`.  The bogus error
disappeared when I removed the ## from the macro's implementation.


Bug 9764 looks like the exact same issue, reported against GCC 2.95, confirmed,
and resolved as "fixed" in 2003. Well, the bug is back again!
Bug 56825 (filed against 4.7 and currently unconfirmed) also looks like a
possible duplicate.


Clang 3.4 and 3.5 have the same bug, possibly out of respect for GCC 4
compatibility. I'm reporting it to them as well, and will post the link here
when I have done it.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug target/61081] excessive warnings: right-hand operand of comma expression has no effect
  2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
                   ` (6 preceding siblings ...)
  2014-06-25 19:16 ` manu at gcc dot gnu.org
@ 2015-02-10 21:01 ` pinskia at gcc dot gnu.org
  7 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2015-02-10 21:01 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Maybe we can fixincludes them or something similar.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-02-10 21:01 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-06 18:05 [Bug c/61081] New: excessive warnings: right-hand operand of comma expression has no effect peter_e at gmx dot net
2014-05-06 18:29 ` [Bug c/61081] " mpolacek at gcc dot gnu.org
2014-05-06 18:33 ` peter_e at gmx dot net
2014-05-06 19:03   ` Marek Polacek
2014-05-06 19:03 ` polacek at redhat dot com
2014-05-08  0:17 ` peter_e at gmx dot net
2014-05-16 20:19 ` peter_e at gmx dot net
2014-05-23 15:39 ` mpolacek at gcc dot gnu.org
2014-06-25 19:16 ` manu at gcc dot gnu.org
2015-02-10 21:01 ` [Bug target/61081] " pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).