This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))


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

--- Comment #17 from Filipe Brandenburger <filbranden at google dot com> ---
To make matters even worse, gcc doesn't even seem to be consistent with itself,
because in other situations it *does* accept a cast to void to silent warnings.

For example, -Wunused-but-set-variable with this test program (on gcc 4.8.2 on
Ubuntu):

  void will_not_warn() {
    int i __attribute__((unused));
    i = 1;
  }

  void should_warn() {
    int i;
    i = 1;
  }

  void should_not_warn() {
    int i;
    i = 1;
    (void) i;
  }

See how there's no warning for should_not_warn which uses the (void) cast:

  $ gcc -c -Wunused-but-set-variable test2.c                                    
  test2.c: In function âshould_warnâ:
  test2.c:8:7: warning: variable âiâ set but not used
[-Wunused-but-set-variable]
     int i;
         ^

And the same with -Wunused-parameter, see this test program:

  int should_warn(int argument) {
    return 0;
  }

  int should_not_warn(int argument) {
    (void) argument;
    return 0;
  }


And the warning, again no warning in should_not_warn which uses the cast to
void:

  $ gcc -c -Wunused-parameter test3.c 
  test3.c: In function âshould_warnâ:
  test3.c:2:21: warning: unused parameter âargumentâ [-Wunused-parameter]
   int should_warn(int argument) {
                       ^

And, to reiterate, you already *can* ignore the value of a warn_unused_result
function, all you have to do is store it in an otherwise unused variable. You
could even use a "(void) ignored;" on that variable on the following line to
silent warnings related to it being set and not used!

So I really don't see the big deal about saying that a cast to void in a
function result should not count as the coder saying that they explicitly
intend to disregard the return value of that function call.

I do agree with you that that code should have comments to indicate why it's
being disregarded and so on and that projects might want to create specific
macros to do it but I think that's the prerrogative of projects using these
features to decide how they'd like to handle it.

Cheers,
Filipe

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]