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

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

[rusty at rustcorp dot com.au]

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

            Bug ID: 66425
           Summary: (void) cast doesn't suppress
                    __attribute__((warn_unused_result))
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rusty at rustcorp dot com.au
  Target Milestone: ---

Yes, a repeat of 2005's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509

The world, especially glibc and the Linux kernel, have adopted __wur with a
passion, taking it well outside the "must" case (basically, realloc and nothing
else) into the "should" case.  For better or worse.

Thus I politely request that an explicit (void) cast work to disable this
warning.  Having projects create their own custom macros/templates to do this
is a worse outcome, and doesn't stop idiocy like ignoring realloc() anyway.

Please consider.
PS.  Happy to create a patch, if that would help.

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I am not the one who decides, but the conclusion of the previous discussion was
that users of _wur (which are the API maintainers adding it) do want to get a
warning even with (void) and GCC's testsuite explicitly tests for it.

It is fairly easy to use -Wno-unused-result or "#pragma GCC diagnostics" if you
want more fine-tuning. The location info in GCC has improved to the point that
it is possible to ignore individual warnings using #pragmas. That seems far
clearer to a reader and makes obvious which warning is ignored on purpose.

Of course, we are happy to get as much help as we can, but I would not want you
to waste your time on something that is likely not going to get approved.
>From gcc-bugs-return-488141-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 05 07:51:41 2015
Return-Path: <gcc-bugs-return-488141-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 84995 invoked by alias); 5 Jun 2015 07:51:41 -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 84957 invoked by uid 48); 5 Jun 2015 07:51:38 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/66423] [6 Regression] a % (1 << b) no longer gets folded to a & (1 << b) for unsigned a
Date: Fri, 05 Jun 2015 07:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
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: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66423-4-mAmlhxyGxp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66423-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66423-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-06/txt/msg00473.txt.bz2
Content-length: 140

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

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
ITYM a & ((1 << b) - 1)

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

[filbranden at google dot com]

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

Filipe Brandenburger <filbranden at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |filbranden at google dot com

--- Comment #2 from Filipe Brandenburger <filbranden at google dot com> ---
It turns out clang from LLVM seems to do the right thing here...

Using this as a test case:

  __attribute__((warn_unused_result))
  int foo() {
    return -1;
  }

  int should_not_warn() {
     return foo();
  }

  int should_warn() {
     foo();
     return 0;
  }

  int void_cast_should_not_warn() {
     (void) foo();
     return 0;
  }

With gcc 5.1:

  $ gcc -c test.c 
  test.c: In function ‘should_warn’:
  test.c:12:4: warning: ignoring return value of ‘foo’, declared with attribute
warn_unused_result [-Wunused-result]
      foo();
      ^
  test.c: In function ‘void_cast_should_not_warn’:
  test.c:17:4: warning: ignoring return value of ‘foo’, declared with attribute
warn_unused_result [-Wunused-result]
      (void) foo();
      ^

With clang 3.5:

  $ clang-3.5 -c test.c 
  test.c:12:4: warning: ignoring return value of function declared with
warn_unused_result attribute [-Wunused-result]
     foo();
     ^~~
  1 warning generated.

Other static analysis tools seem to also take a hint out of the (void) cast.

I mean, why make the programmer jump through hoops and store the return value
in an unused variable? Isn't the (void) cast more explicit than that anyways?

Right now the only choice I can see is to use -Wno-unused-result which
basically makes the feature useless when building using gcc...

Richard Blener proposed a patch here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509#c10

Would it make sense to adopt that patch?

Cheers,
Filipe
>From gcc-bugs-return-488678-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 00:52:55 2015
Return-Path: <gcc-bugs-return-488678-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 83156 invoked by alias); 11 Jun 2015 00:52:55 -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 77592 invoked by uid 48); 11 Jun 2015 00:52:51 -0000
From: "wong.terry at yandex dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66498] New: internal compiler error when compiling chrome and webkit
Date: Thu, 11 Jun 2015 00:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wong.terry at yandex dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-66498-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01010.txt.bz2
Content-length: 4994

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

            Bug ID: 66498
           Summary: internal compiler error when compiling chrome and
                    webkit
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wong.terry at yandex dot com
  Target Milestone: ---

I am find and error with gcc 5.1 from gentoo when building chrome and
libreoffice.

The compiler is 
gcc version 5.1.0 (Gentoo 5.1.0 p1.1, pie-0.6.3) with mpfr-3.1.2_p10 and
dev-libs/isl-0.14


The offence is:
FAILED: x86_64-pc-linux-gnu-g++ -MMD -MF
obj/third_party/WebKit/Source/platform/audio/blink_platform.DynamicsCompressorKernel.o.d
-DV8_DEPRECATION_WARNINGS -D_FILE_OFFSET_BITS=64 -DDISABLE_NACL
-DCHROMIUM_BUILD -DTOOLKIT_VIEWS=1 -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1
-DUSE_ASH=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_DEFAULT_RENDER_THEME=1
-DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1 -DUSE_CLIPBOARD_AURAX11=1
-DENABLE_ONE_CLICK_SIGNIN -DENABLE_PRE_SYNC_BACKUP -DENABLE_REMOTING=1
-DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 -DUSE_PROPRIETARY_CODECS
-DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS
-DUSE_UDEV -DDONT_EMBED_BUILD_METADATA -DENABLE_TASK_MANAGER=1
-DENABLE_EXTENSIONS=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1
-DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_BACKGROUND=1
-DENABLE_GOOGLE_NOW=1 -DCLD_VERSION=2 -DENABLE_PRINTING=1
-DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1
-DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1
-DENABLE_SUPERVISED_USERS=1 -DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1
-DV8_USE_EXTERNAL_STARTUP_DATA -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD
-DSAFE_BROWSING_DB_LOCAL -DSAFE_BROWSING_SERVICE
-DBLINK_PLATFORM_IMPLEMENTATION=1 -DINSIDE_BLINK
-DENABLE_LAYOUT_UNIT_IN_INLINE_BOXES=0
-DWTF_USE_CONCATENATED_IMPULSE_RESPONSES=1 -DENABLE_INPUT_MULTIPLE_FIELDS_UI=1
-DENABLE_WEB_AUDIO=1 -DWTF_USE_WEBAUDIO_FFMPEG=1
-DWTF_USE_DEFAULT_RENDER_THEME=1 -DSK_SUPPORT_GPU=1
-DSK_LEGACY_DRAWPICTURECALLBACK -DSK_SUPPORT_LEGACY_OPTIONLESS_GET_PIXELS
-DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DU_USING_ICU_NAMESPACE=0
-DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION -DENABLE_WEBP
-DUSE_SYSTEM_LIBJPEG -D__STDC_CONSTANT_MACROS -DUSE_LIBPCI=1 -DUSE_GLIB=1
-DUSE_NSS_CERTS=1 -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -D_FORTIFY_SOURCE=2
-Igen/shim_headers/harfbuzz-ng/target -Igen/shim_headers/libpng/target
-Igen/shim_headers/libevent/target -Igen/shim_headers/zlib/target -Igen
-I../../third_party/angle/include -Igen/blink -I../../third_party/ffmpeg
-I../../third_party/WebKit/Source -I../.. -I../../skia/config
-I../../third_party/khronos -I../../gpu -I../../third_party/WebKit
-I../../third_party/skia/include/core -I../../third_party/skia/include/effects
-I../../third_party/skia/include/pdf -I../../third_party/skia/include/gpu
-I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops
-I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports
-I../../third_party/skia/include/utils -I../../skia/ext
-I../../third_party/icu/source/i18n -I../../third_party/icu/source/common
-I../../third_party/ots/include -I../../third_party/qcms/src -I../../v8/include
-I../../third_party/iccjpeg -Igen/ffmpeg
-I../../third_party/ffmpeg/chromium/config/Chrome/linux/x64
-I../../third_party/ffmpeg -fstack-protector --param=ssp-buffer-size=4 
-pthread -fno-strict-aliasing -Wall -Wno-unused-parameter
-Wno-missing-field-initializers -fvisibility=hidden -pipe -fPIC
-Wno-unused-local-typedefs -I/usr/include/libpng16 -I/usr/include/harfbuzz
-I/usr/include/freetype2 -m64 -march=x86-64 -O2 -fno-ident -fdata-sections
-ffunction-sections -funwind-tables -O2 -pipe -fno-exceptions -fno-rtti
-fno-threadsafe-statics -fvisibility-inlines-hidden -Wsign-compare
-Wno-c++0x-compat -std=gnu++11 -Wno-narrowing -Wno-literal-suffix  -c
../../third_party/WebKit/Source/platform/audio/DynamicsCompressorKernel.cpp -o
obj/third_party/WebKit/Source/platform/audio/blink_platform.DynamicsCompressorKernel.o
<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined
<built-in>: note: this is the location of the previous definition
../../third_party/WebKit/Source/platform/audio/DynamicsCompressorKernel.cpp: In
member function ‘void blink::DynamicsCompressorKernel::process(const float**,
float**, unsigned int, unsigned int, float, float, float, float, float, float,
float, float, float, float, float, float)’:
../../third_party/WebKit/Source/platform/audio/DynamicsCompressorKernel.cpp:202:6:
internal compiler error: Floating point exception
 void DynamicsCompressorKernel::process(const float* sourceChannels[],
>From gcc-bugs-return-488679-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 00:53:01 2015
Return-Path: <gcc-bugs-return-488679-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 87975 invoked by alias); 11 Jun 2015 00:53:01 -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 84902 invoked by uid 48); 11 Jun 2015 00:52:56 -0000
From: "filbranden at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/25509] can't disable __attribute__((warn_unused_result))
Date: Thu, 11 Jun 2015 00:53: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.1.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: filbranden at google dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
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
Message-ID: <bug-25509-4-aq51p7ahq3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-25509-4@http.gcc.gnu.org/bugzilla/>
References: <bug-25509-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-06/txt/msg01011.txt.bz2
Content-length: 642

https://gcc.gnu.org/bugzilla/show_bug.cgi?id%509

Filipe Brandenburger <filbranden at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |filbranden at google dot com

--- Comment #31 from Filipe Brandenburger <filbranden at google dot com> ---
See bug 66425 for the cast to (void) to ignore warn_unused_result for a single
case:

It looks like clang is already doing the right thing here...
https://gcc.gnu.org/bugzilla/show_bug.cgi?idf425#c2

gcc should catch up.

Cheers,
Filipe

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

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Filipe Brandenburger from comment #2)
> It turns out clang from LLVM seems to do the right thing here...

There is no right thing here.  In fact some could argue that clang is doing the
wrong thing here.  GCC originally added this attribute and made the decision
then that void would not suppress the attribute.

There are even tests in the GCC testsuite testing that.


https://gcc.gnu.org/ml/gcc-patches/2003-09/msg00851.html

Also unlike most other extensions this one is well documented and even
documents that it warns for this case.

I am going to say people are mis-using this attribute and clang's attribute
does not match up with GCC's attribute.  Just the way life is.

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

[koct9i at gmail dot com]

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

Konstantin Khlebnikov <koct9i at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |koct9i at gmail dot com

--- Comment #5 from Konstantin Khlebnikov <koct9i at gmail dot com> ---
Is it possible to split this case into separate (sub)option
-Wcast-unused-to-void to make this thing backward compatible? Because this is
really annoying.

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

[filbranden at google dot com]

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

--- Comment #6 from Filipe Brandenburger <filbranden at google dot com> ---
Then please explain to me how this:

  (void) foo();

is any worse than this:

  int ignored __attribute__((unused));
  ignored = foo();
  /* do nothing with ignored here */

You can force me to assign the return value to something, but you can't really
force me to do something useful with it...

In the cases above, I think the former is a much more clear way to express my
intent to ignore that value, I'm telling the compiler "yeah, I know, I'm
supposed to use this value, but in this particular case I really know what I'm
doing so please bear with me here."

The -Wunused-result warnings would be a lot more useful (or, actually, just
useful) if I was able to whitelist the places where I want to ignore the
values, since right now my only practical choice is to disable it completely
with -Wno-unused-result.

This is an example of a *real* problem that would have been caught by this
warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509#c28

And it's not just LLVM... Other linters and static analysis tools seem to agree
that a (void) cast is an explicit indication that the coder meant to ignore
those results, so why would gcc want to be the one exception here?

Thanks!
Filipe

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

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Filipe Brandenburger from comment #6)
> Then please explain to me how this:
> 
>   (void) foo();
> 
> is any worse than this:
> 
>   int ignored __attribute__((unused));
>   ignored = foo();
>   /* do nothing with ignored here */
> 
> You can force me to assign the return value to something, but you can't
> really force me to do something useful with it...

I am not forcing you to do anything.  You (or others) are forcing yourself by
using this attribute.  GCC is not forcing you to use this attribute at all. 
You just don't the deinfition of the attribute which was decided on over 10
years ago.  Yes 10 years.  clang was not around back then.  So one could say
clang's attribute is not a copy of GCC's but rather a different one all
together.

> 
> In the cases above, I think the former is a much more clear way to express
> my intent to ignore that value, I'm telling the compiler "yeah, I know, I'm
> supposed to use this value, but in this particular case I really know what
> I'm doing so please bear with me here."
> 
> The -Wunused-result warnings would be a lot more useful (or, actually, just
> useful) if I was able to whitelist the places where I want to ignore the
> values, since right now my only practical choice is to disable it completely
> with -Wno-unused-result.
> 
> This is an example of a *real* problem that would have been caught by this
> warning:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509#c28

Except that assert definition is broken, the standard assert macro in C/C++
does not have any side effects for NDEBUG.  And actually that does not show a
real problem with the attribute but rather they have asserts which have side
effects so they worked out that problem by defining their own assert :).  Still
not a GCC bug :).

> 
> And it's not just LLVM... Other linters and static analysis tools seem to
> agree that a (void) cast is an explicit indication that the coder meant to
> ignore those results, so why would gcc want to be the one exception here?

Again this has nothing to do with other lints, this attribute was designed so
you can't ignore the return value.  And most lints/static analysis tools will
also look to see if you not really ignoring the return value in that you use it
in an error case fashion.  casting to void does not always cause (and really
should not cause) static analysis to ignore what you did was broken for the
API.  It is not GCC's fault people are starting to misuse this attribute; you
should write into those projects instead saying they are misunderstanding the
attribute is being used incorrectly.  I bet some of them, really don't want a
warning even with a cast to void.

> 
> Thanks!
> Filipe

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

[filbranden at google dot com]

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

--- Comment #8 from Filipe Brandenburger <filbranden at google dot com> ---
(In reply to Andrew Pinski from comment #7)
> Again this has nothing to do with other lints, this attribute was designed
> so you can't ignore the return value.

I obviously *can* ignore the return value, just assign it to an unused variable
that I ignore...

By pretending that warn_unused_result can only be used in cases where the
return value can never be ignored with no exceptions (which, as mentioned
above, is not really impossible to enforce) you just end up making
-Wunused-result totally unusable.

> > This is an example of a *real* problem that would have been caught by
> > this warning:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509#c28
> 
> Except that assert definition is broken, the standard assert macro in C/C++
> does not have any side effects for NDEBUG.

My point was actually about:

  v.empty();   // v.clear() was intended!

Even without that assert() definition (which I imagine was done that way to
prevent breaking code that relied on the side effects of the expressions inside
it), it's basically impossible to enable it since then there's no good way
(except for the horrible bogus hacky ignored variable) to create exceptions to
the rule.

Just because this option was introduced 10 years ago, because you invented it
first, because you wrote unit tests to ensure this behavior, doesn't mean that
it's correct or that it's useful the way it is... Please reconsider.

I think it would be fine fine if you wanted to introduce an even stronger
__attribute__((error_unused_result)) or similar that allows no exceptions,
which could then be used for say malloc() or realloc() where there's really
*really* no excuse to not save the return value, but I really don't see the
point since there are always ways around it...

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

[filbranden at google dot com]

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

--- Comment #9 from Filipe Brandenburger <filbranden at google dot com> ---
Or, conversely, please explain to me how changing the behavior (to allow a
void-cast to silent the warning on a call to a warn_unused_result function)
would actually affect anyone today...

If it's a project that's actually using -Wunused-result (and they actually look
at those warnings and care about them), then they're not really using a
void-cast to ignore the return value, otherwise they would get a warning. Would
the change of behavior really affect them? Not really.

If they're using -Wunused-result but do not care about the warnings, well, do
we really care? If anything (perhaps if they were adding void-casts for linters
and other static analysis tools) it's possible that a lot of suprious warnings
will be suppressed and they'll be left with a more manageable list and possibly
start to actually look at those and fix them (since there's an easy way to
explicitly say they should be ignored.)

If they're using -Wno-unused-result, then the change of behavior doesn't affect
them. If anything, if this *BUG* is fixed, they might actually reconsider and
re-enable it.

So please explain to me why sticking to the current unhelpful behavior is
really that important.

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

[lucas.de.marchi at gmail dot com]

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

Lucas De Marchi <lucas.de.marchi at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lucas.de.marchi at gmail dot com

--- Comment #10 from Lucas De Marchi <lucas.de.marchi at gmail dot com> ---
(In reply to Andrew Pinski from comment #7)
> Again this has nothing to do with other lints, this attribute was designed
> so you can't ignore the return value.  And most lints/static analysis tools
> will also look to see if you not really ignoring the return value in that
> you use it in an error case fashion.  casting to void does not always cause
> (and really should not cause) static analysis to ignore what you did was
> broken for the API.  It is not GCC's fault people are starting to misuse
> this attribute; you should write into those projects instead saying they are
> misunderstanding the attribute is being used incorrectly.  I bet some of
> them, really don't want a warning even with a cast to void.

You are ignoring the fact that the places in which the attribute is put is
often out of control for those using that interface.  This means they can't
really remove the attribute or also that the attribute may make sense in MOST
of the cases but not in that particular one.

Casting to void is nowadays the de facto standard to say "I really know what
I'm doing and I don't care about the return value *here*".  This is way better
then letting each project invent their all workaround macros and even risk
doing the wrong thing like the assert you pointed out as wrong.

So maybe after 10 years it's time to revisit that decision?  It's not that the
behavior of when warnings are emitted are really set in stone and never
changed. It pretty much did all this time and we kept adapting to it.

If just changing the behavior is not acceptable then maybe splitting the
-Wunused-result to let people ignore this particular case of cast to void as
suggested would be good.

The gcc vs clang vs linters debate and who invented the attribute don't belong
to this discussion. It's better to discuss why we can't let the attribute be
actually useful by letting the users to turn it off when they know what they
are doing.

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

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Some remarks before the discussion gets out of hand.

Neither Andrew nor me nor other people that may comment here have the power to
approve or reject this change. The people you need to convince are the C/C++ FE
maintainers listed in the MAINTAINERS file. Some of them are also GNU libc
maintainers, thus actual users of the _wur attribute. We are just trying to
make you understand the context in which the decision *made by others* has been
made.

> Casting to void is nowadays the de facto standard to say "I really know what
> I'm doing and I don't care about the return value *here*".  This is way
> better then letting each project invent their all workaround macros and even
> risk doing the wrong thing like the assert you pointed out as wrong.

This cannot be true, because the most heavy users of _wur are the kernel and
glibc, and the de-facto standard to compile those is GCC. 

How can "(void) foo(x)" be clearer than "ignore_unused_result(foo(x))" ?

Perhaps you could ask GNU libc to provide such non-standard macro
"ignore_unused_result" to avoid every project inventing their own.

Instead of '(void)', a patch that provides a __no_warn__ keyword as a
short-hand might be more acceptable (again, you don't have to convince us, just
the FE maintainers).

> So maybe after 10 years it's time to revisit that decision?  It's not that
> the behavior of when warnings are emitted are really set in stone and never
> changed. It pretty much did all this time and we kept adapting to it.

That is not so true, believe me. As someone that has been contributing to GCC
diagnostics for the last 10 years, changing GCC diagnostics ALWAYS breaks
someone's setup and they will be unhappy about it (https://xkcd.com/1172/).

That said, the best strategy to change the defaults is not to argue here in
this PR. The best strategy would be to collect the opinion from the most heavy
users of _wur (that is, GNU libc and the kernel maintainers, not their users
nor random people in their mailing lists), present a patch and argue
convincingly to the FE maintainers that this should change (not because Clang
is using it, but because the people using GCC want it).

> The gcc vs clang vs linters debate and who invented the attribute don't
> belong to this discussion. It's better to discuss why we can't let the
> attribute be actually useful by letting the users to turn it off when they
> know what they are doing.

That way of arguing is self-defeating, I'm sorry to say. The attribute is
actually useful because people are using it, otherwise, you would not even have
noticed that it exists.
>From gcc-bugs-return-488713-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 08:49:39 2015
Return-Path: <gcc-bugs-return-488713-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 86750 invoked by alias); 11 Jun 2015 08:49:38 -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 86696 invoked by uid 48); 11 Jun 2015 08:49:33 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
Date: Thu, 11 Jun 2015 08:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
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: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66448-4-b1R9jks1vI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66448-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66448-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-06/txt/msg01045.txt.bz2
Content-length: 1067

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

--- Comment #19 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(In reply to Iain Sandoe from comment #18)
> > Could you test it properly on darwin?
>
> $ grep -rH "invalid DW" gcc/testsuite |wc -l
>       0

Confirmed on x86_64-apple-darwin14 with
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto. Thanks.

> OK - so now I have one remaining problem.  The change in my intial patch to
> make the creation of the "extern int __CFConstantStringClassReference" lazily,
> regresses obj-c++ (and, yes, I do care - it's needed to build some interesting
> projects).

Confirmed.

> (we need to move forward to unbreak Darwin bootstrap, so that we don't get
> behind on catching other things - so I'd be inclined to the original patch as
> band-aid, in the interim, if all elase fails)

IMO the priority is to fix the bootstrap and test suite failures. Once this is
done, it will be time to file PR(s) for the remaining issue(s).

Note that pr65809 has been fixed between r224139 (FAIL) and r224288.

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

[schwab@linux-m68k.org]

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

--- Comment #13 from Andreas Schwab <schwab@linux-m68k.org> ---
> I don't really see why the trouble making the mental connection from the
> void cast with the coder's intent do discard that result. Could it mean
> anything else really?

The C language doesn't define any such meaning.  The cast is redundant as far
as the standard is concerned.

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

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6914 bytes --]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
                 CC|manu at gcc dot gnu.org            |
         Resolution|INVALID                     |---

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Filipe Brandenburger from comment #12)
> Can I have this issue reopened please?

If that makes you happy...

> Ok, how can we assign this bug to the appropriate team then?

It doesn't work like that. Individual contributors will work on things that
they find interesting or get paid to fix.

> I can't really think of a situation in the Linux kernel source code where
> I'd find a __must_check function with a void cast, exactly for that reason,
> right now it would generate a warning.

The users of _wur added _wur to a function expecting that any use of this
function that does not assign the result will get a warning, even if there is a
cast to void. Not warning for a cast to void breaks that expectation.

In any case, I simply tried to bring some clarity of why some people are
contesting this and how you may get what you desire (and how you may not). I
personally do not mind whether 'void' silences _wur or not. Good luck!
>From gcc-bugs-return-488774-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 14:28:05 2015
Return-Path: <gcc-bugs-return-488774-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 95358 invoked by alias); 11 Jun 2015 14:28:05 -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 94758 invoked by uid 48); 11 Jun 2015 14:28:01 -0000
From: "jgreenhalgh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/66510] New: gcc.target/arm/pr53636.c FAILs after r224221
Date: Thu, 11 Jun 2015 14:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jgreenhalgh at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone cf_gcctarget attachments.created
Message-ID: <bug-66510-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-06/txt/msg01106.txt.bz2
Content-length: 3506

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

            Bug ID: 66510
           Summary: gcc.target/arm/pr53636.c FAILs after r224221
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jgreenhalgh at gcc dot gnu.org
                CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
            Target: arm-none-eabi, arm-none-linux-gnueabihf

Created attachment 35762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5762&actioníit
Minimal reproduced (derived from gcc.target/arm/pr53636.c )

r224221 caused an ICE in the ARM port (arm-none-eabi,
arm-none-linux-gnueabihf):

    FAIL: gcc.target/arm/pr53636.c (internal compiler error)

Full ICE text below, and reduced testcase attached (bug.c), compile with:

    arm-none-eabi-gcc -O -ftree-vectorize -mfpu=neon -mcpu=cortex-a9
-mfloat-abi=hard bug.c

I tried to take a look to see what was happening, but I couldn't see
the root of the problem. The access to dr_chain in
vect_create_mask_and_perm:

    second_vec = dr_chain[second_vec_indx];

Fails as dr_chain has length 1, and second_vec_indx is 2.

I think that the mask that the code is trying to produce is { 1, 2, 3, 4 }.

    bug.c:4:3: note: add new stmt: vect__8.6_108 = VEC_PERM_EXPR
<vect__8.4_104, vect__8.5_106, { 1, 2, 3, 4 }>;

But that's about as far as I got.

Thanks,
James

---
bug.c: In function 'test':
bug.c:1:6: internal compiler error: in operator[], at vec.h:738
 void test(unsigned char *dst) {
      ^
0xd759fe vec<tree_node*, va_heap, vl_embed>::operator[](unsigned int)
        .../src/gcc/gcc/vec.h:738
0xd759fe vec<tree_node*, va_heap, vl_ptr>::operator[](unsigned int)
        .../src/gcc/gcc/vec.h:1204
0xd759fe vect_create_mask_and_perm
        .../src/gcc/gcc/tree-vect-slp.c:3072
0xd759fe vect_transform_slp_perm_load(_slp_tree*, vec<tree_node*, va_heap,
vl_ptr>, gimple_stmt_iterator*, int, _slp_instance*, bool)
        .../src/gcc/gcc/tree-vect-slp.c:3350
0xd51613 vectorizable_load
        .../src/gcc/gcc/tree-vect-stmts.c:6847
0xd57ad2 vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*,
bool*, _slp_tree*, _slp_instance*)
        .../src/gcc/gcc/tree-vect-stmts.c:7490
0xd7aac1 vect_schedule_slp_instance
        .../src/gcc/gcc/tree-vect-slp.c:3500
0xd7a117 vect_schedule_slp_instance
        .../src/gcc/gcc/tree-vect-slp.c:3381
0xd7a117 vect_schedule_slp_instance
        .../src/gcc/gcc/tree-vect-slp.c:3381
0xd7a117 vect_schedule_slp_instance
        .../src/gcc/gcc/tree-vect-slp.c:3381
0xd7a117 vect_schedule_slp_instance
        .../src/gcc/gcc/tree-vect-slp.c:3381
0xd7a117 vect_schedule_slp_instance
        .../src/gcc/gcc/tree-vect-slp.c:3381
0xd7a117 vect_schedule_slp_instance
        .../src/gcc/gcc/tree-vect-slp.c:3381
0xd7a117 vect_schedule_slp_instance
        .../src/gcc/gcc/tree-vect-slp.c:3381
0xd7abce vect_schedule_slp(_loop_vec_info*, _bb_vec_info*)
        .../src/gcc/gcc/tree-vect-slp.c:3570
0xd5e564 vect_transform_loop(_loop_vec_info*)
        .../src/gcc/gcc/tree-vect-loop.c:6223
0xd7eca8 vectorize_loops()
        .../src/gcc/gcc/tree-vectorizer.c:499
0xc88c54 execute
        .../src/gcc/gcc/tree-ssa-loop.c:292
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

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

[lucas.de.marchi at gmail dot com]

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

--- Comment #15 from Lucas De Marchi <lucas.de.marchi at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #14)
> (In reply to Filipe Brandenburger from comment #12)
> > Can I have this issue reopened please?
> 
> If that makes you happy...
> 
> > Ok, how can we assign this bug to the appropriate team then?
> 
> It doesn't work like that. Individual contributors will work on things that
> they find interesting or get paid to fix.

Rusty, who opened this issue, seemed inclined to prepare such a patch.

> > I can't really think of a situation in the Linux kernel source code where
> > I'd find a __must_check function with a void cast, exactly for that reason,
> > right now it would generate a warning.
> 
> The users of _wur added _wur to a function expecting that any use of this
> function that does not assign the result will get a warning, even if there
> is a cast to void. Not warning for a cast to void breaks that expectation.

As I said, the people who add the attribute may not be the same people who use
the interface with that attribute.  I myself when writing libraries use the
_wur to give my users a warning if they are ignoring the return value.  However
they have all the rights to ignore it.  Be it simply by not using
-Wunused-result, hacking a macro to ignore the result or use the de facto
standard to cast to void.  IMO the latter is the best one since there might be
1 particular case in the entire codebase in which ignoring the return makes
sense.
>From gcc-bugs-return-488783-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 15:12:33 2015
Return-Path: <gcc-bugs-return-488783-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 63856 invoked by alias); 11 Jun 2015 15:12:32 -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 63780 invoked by uid 48); 11 Jun 2015 15:12:29 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/52998] different macro unwinder for C and C++ (-ftrack-macro-expansion)
Date: Thu, 11 Jun 2015 15:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-52998-4-mL4htitHtZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52998-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52998-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-06/txt/msg01115.txt.bz2
Content-length: 439

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

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

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 66500 has been marked as a duplicate of this bug. ***

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

[joseph at codesourcery dot com]

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

--- Comment #16 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I'd say that for any function for which use of this attribute is 
appropriate, suppression of the warning should involve a detailed comment 
explaining why the particular use of the function is so exceptional that, 
very unusually, it is not possible to (for example) do anything useful 
with the information that the function call failed or it is otherwise 
exceptionally safe to ignore the result - and that any suppression of the 
warning should involve extra-careful code review when added.

See, for example, how glibc handles use of diagnostic suppression pragmas, 
via macros DIAG_PUSH_NEEDS_COMMENT, DIAG_IGNORE_NEEDS_COMMENT and 
DIAG_POP_NEEDS_COMMENT, to make it extra-obvious if a patch is adding such 
uses and to make it obvious at the use site that such comments are needed.

Now, the compiler cannot check whether an explanatory comment justifying 
diagnostic suppression is present, and cannot know how a particular 
project wishes to handle justifying exceptions to its normal coding style 
rules.  But it can make it as visible as possible that something unusual 
and dubious is being done by ignoring the return value, to reduce the 
chance of it slipping by reviewers.

I'd say that a warning suppressed by a (void) cast should be a separate 
attribute, e.g. warn_unused_result_weak.

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

[filbranden at google dot com]

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
>From gcc-bugs-return-488808-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 17:06:31 2015
Return-Path: <gcc-bugs-return-488808-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 129926 invoked by alias); 11 Jun 2015 17:06: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 129881 invoked by uid 48); 11 Jun 2015 17:06:27 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66515] [5/6 Regression] g++ segfaults when creating an std::initializer_list
Date: Thu, 11 Jun 2015 17:06: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: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
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: bug_status cf_reconfirmed_on cc cf_known_to_work short_desc everconfirmed cf_known_to_fail
Message-ID: <bug-66515-4-PuS9DZVPbK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66515-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66515-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01140.txt.bz2
Content-length: 3399

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-11
                 CC|                            |trippels at gcc dot gnu.org
      Known to work|                            |4.8.4, 4.9.2
            Summary|g++ segfaults when creating |[5/6 Regression] g++
                   |an std::initializer_list    |segfaults when creating an
                   |                            |std::initializer_list
     Ever confirmed|0                           |1
      Known to fail|                            |5.0, 6.0

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
markus@x4 tmp % cat bug_gcc.ii
namespace std
{
template <class _E> class initializer_list
{
  const _E *_M_array;
  unsigned long _M_len;
};
}

struct type_t
{
};
type_t &
get ()
{
  std::initializer_list<type_t>{ { get () } };
}

markus@x4 tmp % g++ -std=c++11 bug_gcc.ii
bug_gcc.ii: In function ‘type_t& get()’:
bug_gcc.ii:16:45: internal compiler error: tree check: expected constructor,
have indirect_ref in build_aggr_conv, at cp/call.c:946
   std::initializer_list<type_t>{ { get () } };
                                             ^
0xf3f0bc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
        ../../gcc/gcc/tree.c:9379
0x5cd1bf tree_check(tree_node*, char const*, int, char const*, tree_code)
        ../../gcc/gcc/tree.h:2858
0x5cd1bf build_aggr_conv
        ../../gcc/gcc/cp/call.c:946
0x5cd1bf implicit_conversion
        ../../gcc/gcc/cp/call.c:1856
0x5cccf9 build_list_conv
        ../../gcc/gcc/cp/call.c:829
0x5cccf9 implicit_conversion
        ../../gcc/gcc/cp/call.c:1807
0x5cd97e reference_binding
        ../../gcc/gcc/cp/call.c:1532
0x5cc504 implicit_conversion
        ../../gcc/gcc/cp/call.c:1797
0x5ce8e2 add_function_candidate
        ../../gcc/gcc/cp/call.c:2106
0x5cfde7 add_candidates
        ../../gcc/gcc/cp/call.c:5283
0x5d0124 add_list_candidates
        ../../gcc/gcc/cp/call.c:3546
0x5d0ff3 build_new_method_call_1
        ../../gcc/gcc/cp/call.c:8111
0x5d0ff3 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
        ../../gcc/gcc/cp/call.c:8313
0x5d1cc9 build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, tree_node*, int, int)
        ../../gcc/gcc/cp/call.c:7853
0x5d47c3 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
        ../../gcc/gcc/cp/call.c:9506
0x723c87 build_static_cast_1
        ../../gcc/gcc/cp/typeck.c:6576
0x725037 cp_build_c_cast(tree_node*, tree_node*, int)
        ../../gcc/gcc/cp/typeck.c:7256
0x67798a build_functional_cast(tree_node*, tree_node*, int)
        ../../gcc/gcc/cp/typeck2.c:1980
0x755aa9 finish_compound_literal(tree_node*, tree_node*, int)
        ../../gcc/gcc/cp/semantics.c:2614
0x6e0b21 cp_parser_functional_cast
        ../../gcc/gcc/cp/parser.c:23914
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-488809-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 17:14:37 2015
Return-Path: <gcc-bugs-return-488809-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20806 invoked by alias); 11 Jun 2015 17:14:35 -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 20767 invoked by uid 48); 11 Jun 2015 17:14:30 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66516] New: missing diagnostic on taking the address of a builtin function
Date: Thu, 11 Jun 2015 17:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-66516-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-06/txt/msg01141.txt.bz2
Content-length: 1528

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

            Bug ID: 66516
           Summary: missing diagnostic on taking the address of a builtin
                    function
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Gcc accepts without warning code that takes the address of builtin functions
and calls such functions through pointers.  Some such code links and even runs
successfully while other such code fails to link.

For example, code that compiles, links and runs:

$ cat z.c && gcc -Wall z.c && ./a.out
extern int printf (const char*, ...);
unsigned long strlen (const char*);

int main (void)
{
    unsigned long (*p)(const char*) = &__builtin_strlen;

    printf ("&__builtin_strlen = %p\n"
            "&strlen           = %p\n",
            p, &strlen);
}
&__builtin_strlen = 0x400430
&strlen           = 0x400430

Code that compiles but doesn't link involves builtins that don't have
corresponding libc functions.

Clang rejects all such code with an error similar to the following:

z.c:6:40: error: builtin functions must be directly called
    unsigned long (*p)(const char*) = &__builtin_strlen;
                                       ^
1 error generated.

It seems that gcc should reject all code that attempts to take the address of a
builtin the same way Clang does.

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

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

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

--- Comment #18 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Another way of ignoring the unused result, friendlier on the eyes than
ugly macros or horrible casts, and even *inviting* the programmer to
write an explanatory comment, goes like

if (foo()) {
  /* The return value of foo can be ignored here because X and Y.  */
}

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

[rusty at rustcorp dot com.au]

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

--- Comment #21 from rusty at rustcorp dot com.au ---
jengelh at inai dot de <gcc-bugzilla@gcc.gnu.org> writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
>
> --- Comment #20 from Jan Engelhardt <jengelh at inai dot de> ---
> Seems like the short route is to add a new attribute
> ((warn_unused_result_with_void_cancelling)) that exhibits the "desired"
> behavior of (void) cancelling the warning, and then make glibc use that.
> Simple, no?

Indeed!  I'll produce the patch if anyone thinks it's worthwhile?

It'll only take another 10 years to switch everyone :)

Thanks,
Rusty.

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

[filbranden at google dot com]

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

--- Comment #22 from Filipe Brandenburger <filbranden at google dot com> ---
(In reply to Jan Engelhardt from comment #20)
> Seems like the short route is to add a new attribute
> ((warn_unused_result_with_void_cancelling)) that exhibits the "desired"
> behavior of (void) cancelling the warning, and then make glibc use that.
> Simple, no?

I'd rather see ((warn_unused_result_without_void_cancelling)).

Or, better yet, add both in and add a command-line flag to allow
((warn_unused_result)) to use one or the other.

I still don't see the point of preventing (void) from cancelling it since you
can just store the result on an otherwise unused "discard" variable, I mean, if
the programmer *really* wants to ignore the result, they can do it in many
ways, ((warn_unused_result)) is to prevent programming mistakes where the
programmer *meant* to look at the results but mistakenly forgot it...

I also fail to see what else a void cast can mean other than explicitly
indicating that the programmer *knows* the function returns a non-empty value
but decided to ignore it...

Anyways, let's not go on that rant again... If you get to implement the new
attribute that would be awesome!

Cheers,
Filipe

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

[pskocik at gmail dot com]

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

pskocik at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pskocik at gmail dot com

--- Comment #38 from pskocik at gmail dot com ---
I like this behavior. I use (void) casts to suppress warnings about unused
parameters and variables, but I'd rather suppressing WUR weren't that simple
because of functions whose return result represents an allocated resource
(allocated memory, FILE, filedescriptor, etc.), in which case the suppression
is in 99% cases erroneous.

Of course, WUR is also useful as an aid in enforcing consistent error checking
but a codebase using WUR like that might as well define an custom IGNORE macro
(which assigns the result to a properly typed temporary and then voids it) and
make sure such a macro only works on return values which are truly safe to
ignore (e.g., rather than returning plain int, long, etc., you might return
struct ignorable_int { int ignorable_retval; };, struct ignorable_long { long
ignorable_retval; }, etc. and have your ignore macro try and access the
specifically named member).

(An ability to directly attach WUR to such types, which clang has gcc currently
doesn't (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94379), would also go
nicely with this un-void-able WURs feature (although WURs are void-able on
clang)).

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

[ndesaulniers at google dot com]

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

Nick Desaulniers <ndesaulniers at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ndesaulniers at google dot com

--- Comment #39 from Nick Desaulniers <ndesaulniers at google dot com> ---
Cross referencing an LLVM bug on a similar discussion:
https://bugs.llvm.org/show_bug.cgi?id=51228

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

[achurch+gcc at achurch dot org]

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

Andrew Church <achurch+gcc at achurch dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |achurch+gcc at achurch dot org

--- Comment #40 from Andrew Church <achurch+gcc at achurch dot org> ---
Created attachment 54906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54906&action=edit
POC patch to add -Wunused-result=strict

In hopes of moving this along (after having run into it for the third or fourth
time myself), here's a proof-of-concept patch against GCC 12.2.0 which adds
"-Wunused-result=strict" for the current behavior and changes "-Wunused-result"
to ignore cases in which the result is discarded by casting to void.

My rationale for changing the default behavior is that the wider community
consensus, as evidenced by things like the C++ (and C2x) [[nodiscard]]
specification, the behavior of Clang, and the balance of comments on this bug,
seems to be that casting a discarded return value to void should suppress any
warning about the discarded value; and under the principle of least surprise,
GCC should follow that consensus by default even if it also provides
alternative behaviors.

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

[sjames at gcc dot gnu.org]

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

--- Comment #41 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Andrew Church from comment #40)
> Created attachment 54906 [details]
> POC patch to add -Wunused-result=strict
> 

Could you send it to the gcc-patches mailing list please? (Even if it is a
PoC).

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

[achurch+gcc at achurch dot org]

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

--- Comment #42 from Andrew Church <achurch+gcc at achurch dot org> ---
(In reply to Sam James from comment #41)
> Could you send it to the gcc-patches mailing list please? (Even if it is a
> PoC).

Sent as requested.

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

[segher at gcc dot gnu.org]

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

--- Comment #43 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Andrew Church from comment #40)
> My rationale for changing the default behavior is that the wider community
> consensus, as evidenced by things like the C++ (and C2x) [[nodiscard]]
> specification, the behavior of Clang, and the balance of comments on this
> bug, seems to be that casting a discarded return value to void should
> suppress any warning about the discarded value; and under the principle of
> least surprise, GCC should follow that consensus by default even if it also
> provides alternative behaviors.

That is not the consensus, no.  "Consensus" does not mean doing what the
unthinking masses shout.

There already are easy ways to deal suppress the error, very direct, and
very descriptive ways.  A cast to void is round-about, cryptic, and already
is cargo-cult, before this attribute existed even!  So allowing casts to void
to suppress this warning means the warning becomes less useful, and people
will write worse code.  That is not something GCC should encourage IMO.

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

[achurch+gcc at achurch dot org]

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

--- Comment #44 from Andrew Church <achurch+gcc at achurch dot org> ---
(In reply to Segher Boessenkool from comment #43)
> That is not the consensus, no.  "Consensus" does not mean doing what the
> unthinking masses shout.

Merriam-Webster disagrees:
con.sen.sus
1 a: general agreement : UNANIMITY
  b: the judgment arrived at by most of those concerned

I specifically clarified that with "wider" to indicate the larger group of "C
compiler users", as opposed to what you seem to mean, "C compiler developers". 
And in whatever sense you choose to regard them, the judgment arrived at by
most C compiler users does seem to be "cast to void should suppress a warning
about a discarded value", as I described above.

> So allowing casts to void
> to suppress this warning means the warning becomes less useful, and people
> will write worse code.  That is not something GCC should encourage IMO.

You seem to think that making the warning harder to work around will encourage
programmers to change their code to fix the warning.  In reality, they are more
likely to either (1) disable the warning entirely or (2) disregard warnings in
general, both of which result in considerably worse code - the situation you
say you are trying to avoid.  Thus my suggestion to follow the principle of
least surprise and allow a void cast to disable the warning by default.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #45 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Church from comment #44)
> (In reply to Segher Boessenkool from comment #43)
> > That is not the consensus, no.  "Consensus" does not mean doing what the
> > unthinking masses shout.
> 
> Merriam-Webster disagrees:
> con.sen.sus
> 1 a: general agreement : UNANIMITY
>   b: the judgment arrived at by most of those concerned

But there is no general agreement at all. If clang behavior agreed with gcc,
then there would be consensus here. In fact gcc behavior is older than clang
behavior makes this even more difficult and even points out that if clang said
it implemented a compatible extension, it did not.



> 
> I specifically clarified that with "wider" to indicate the larger group of
> "C compiler users", as opposed to what you seem to mean, "C compiler
> developers".  And in whatever sense you choose to regard them, the judgment
> arrived at by most C compiler users does seem to be "cast to void should
> suppress a warning about a discarded value", as I described above.
> 

There is still no general consensus really. Just that the folks who want
behavior difference is loud while the ones who are happy with the current
behavior are quiet because they don't need to tell their thoughts on it.




> > So allowing casts to void
> > to suppress this warning means the warning becomes less useful, and people
> > will write worse code.  That is not something GCC should encourage IMO.
> 
> You seem to think that making the warning harder to work around will
> encourage programmers to change their code to fix the warning.  In reality,
> they are more likely to either (1) disable the warning entirely or (2)
> disregard warnings in general, both of which result in considerably worse
> code - the situation you say you are trying to avoid.  Thus my suggestion to
> follow the principle of least surprise and allow a void cast to disable the
> warning by default.

You are basically saying all warnings will be ignored which is true. Even ones
with no false positives are ignored. Using a void cast makes life too easy to
ignore this behavior. If the api user wants to ignore the return values while
the api developer tells you should not, then really the api user will have
bugs. This is why the warning is there. Now api developers have known to place
this attribute on things that should not be placed on but that is not a
compiler issue and the api user should talk with the api developer rather than
try to change the compiler for their workaround.

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

[achurch+gcc at achurch dot org]

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

--- Comment #46 from Andrew Church <achurch+gcc at achurch dot org> ---
(In reply to Andrew Pinski from comment #45)
> But there is no general agreement at all. If clang behavior agreed with gcc,
> then there would be consensus here. In fact gcc behavior is older than clang
> behavior makes this even more difficult and even points out that if clang
> said it implemented a compatible extension, it did not.

First, a single disagreement does not invalidate a consensus, at least in the
general meaning which I quoted ("the judgment arrived at by most of those
concerned" - note "most" and not "all").  As I discussed earlier, I still see
significantly wider support for the view that void casts should silence
discarded-value warnings, to the extent that I consider it fair to call that
view a consensus.

Second, an equally valid view of the meaning of Clang's behavior differing from
GCC's - barring any deeper knowledge of the LLVM team's decision-making, which
I do not have - is that the LLVM team merged the observed intent behind the
original extension (warn about values which should not be discarded) with its
knowledge of existing practice (use of a void cast to indicate a deliberately
discarded value) to arrive at their choice of behavior.  If anything, I'd
suggest that https://bugs.llvm.org/show_bug.cgi?id=51228 being marked WONTFIX
because the developers consider it to be "working as intended" argues for this
view.

> You are basically saying all warnings will be ignored which is true.

That's not what I said, and I disagree at least with that particular phrasing. 
I would, however, accept "warnings will be ignored if the user feels the effort
to fix the warning is not worth the benefit".  By corollary, users in general
will take the path of least resistance to resolving a warning, and if allowing
void casts to silence specific instances of the warning encourages them to
leave the warning enabled in general, it will result in better code than if the
user gets so frustrated with the warning that they just turn it off completely.

> Using a void cast makes life too easy to ignore this behavior.

It still requires action on the part of the programmer.  A programmer who
writes

   system("foo");

may want to be warned that the return code from system() is discarded, whereas
a programmer who writes

   (void) system("foo");

has clearly stated an intent to discard that return value, and warning about it
anyway is unnecessary noise.  (Though an argument could be certainly be made
for a better word than "void", perhaps a construction like "[[discard]]
foo()".)

Is there a risk of cargo-cult syndrome?  (A: "Hey B, how do I call this
external foo program?"  B: "Just write '(void) system("foo")'.")  Certainly. 
But the same argument can be made for _any_ workaround, and I suspect that more
complex workarounds would increase, rather than decrease, that risk - the more
complex the code, the less likely the user is to read it and understand what
it's doing.

> If the api user wants to ignore the return
> values while the api developer tells you should not, then really the api
> user will have bugs. This is why the warning is there.

Demonstrably false (see above, and even your own caveat below).

> Now api developers
> have known to place this attribute on things that should not be placed on
> but that is not a compiler issue and the api user should talk with the api
> developer rather than try to change the compiler for their workaround.

Suppose the API developer's response is, "I don't care about your use case, I
want you to do things my way."  What is the (non-compiler developer) user to do
then?  Look for an alternative library, which may not even exist?  Spend the
time to write their own?  Disable the warning and accept the risk of bugs in
unrelated code?  Look up the workaround du jour and throw it all over their
code base, cargo-cult style?

If I were faced with that choice, I would probably just switch to Clang.

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

[rusty at rustcorp dot com.au]

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

--- Comment #47 from rusty at rustcorp dot com.au ---
Civility please.

We're all trying to find a path to improve things here.  But accept that the
conversation on this issue is only a weak indication of consensus.

As Andrew Pinski says "people are mis-using this attribute", and Jakub Jelinek
makes a similar point.  The use of _wur has changed from "ignoring the result
is criminally wrong" to "possibly wrong".

I still put a comment complaining about this every time I hit it, which is
about once or twice a year.  But I have little more to say; it's been almost 20
year after all :)

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

[achurch+gcc at achurch dot org]

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

--- Comment #48 from Andrew Church <achurch+gcc at achurch dot org> ---
(In reply to rusty from comment #47)
> Civility please.

I have no intention of trying to start a fight :)  Like you, I'm just trying to
improve the situation, and knowing that in my own open-source work I'm always
happier when a user offers a patch instead of just a "please fix this", I've
done the same here.  That said, since I _am_ trying to improve the situation, I
won't step back from debating the utility of the change if the developer
disagrees.  (And I freely admit that I can be tempted into a bit of snark from
time to time...)

> But accept that the
> conversation on this issue is only a weak indication of consensus.

I agree, which is why I gave other examples such as Clang's behavior and
especially the C++/C2x standards.  While I grant that even standards committees
are small subsets of the total user community and are not immune to poor
decision-making, I'd consider the facts that (1) the C++17 description of
[[nodiscard]] called out void casts as a case which should not be diagnosed,
(2) C++20 expanded on that with an explicit example of a cast-to-void call not
being diagnosed, and (3) C2x, as of the current draft, also includes the
call-out of void casts from C++17 (though not the explicit example from C++20),
to collectively be a much stronger indicator of that consensus.

> As Andrew Pinski says "people are mis-using this attribute", and Jakub
> Jelinek makes a similar point.  The use of _wur has changed from "ignoring
> the result is criminally wrong" to "possibly wrong".

I think "mis-using" is a bit harsh; the core concept (warning about a discarded
return value) is a useful one, as evidenced by the feature's adoption into C++
and subsequently C2x.  I grant that it's being used for a wider variety of
purposes than originally intended, but since there was no other option until
the relatively recent addition of [[nodiscard]], that's what people went with.

I was thinking about adding a suggestion for multiple levels of warning, such
as "ignoring this is almost certainly wrong" (e.g. realloc()) vs "ignoring this
could be dangerous, you might want to doublecheck" (e.g. system()); in fact,
[[nodiscard]] is effectively that since void casts do silence [[nodiscard]]
warnings in GCC, though I don't know if the difference in behavior from _wur is
intentional.  But that ultimately wouldn't do anything about the present
problem, which is API developers and users disagreeing on whether a return
value is safe to discard - it might morph into something like "why is this
function marked with the stricter _wur when it should just be [[nodiscard]]",
and we're back to wanting to selectively silence _wur warnings again.

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

[jakub at gcc dot gnu.org]

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

--- Comment #49 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
All that means is for APIs for which cast to void as silencing is meant to be
ok should be using [[nodiscard]] rather than
__attribute__((warn_unused_result)).  APIs which do not want that should keep
using warn_unused_result.  When that attribute was being added, the glibc folks
that requested it specially asked for casts to void not being a way to silence
the attribute because the attributes were added to functions where users really
should use the return value rather than silently ignore it.

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

[fw at gcc dot gnu.org]

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

--- Comment #50 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #49)
> All that means is for APIs for which cast to void as silencing is meant to
> be ok should be using [[nodiscard]] rather than
> __attribute__((warn_unused_result)).  APIs which do not want that should
> keep using warn_unused_result.  When that attribute was being added, the
> glibc folks that requested it specially asked for casts to void not being a
> way to silence the attribute because the attributes were added to functions
> where users really should use the return value rather than silently ignore
> it.

I don't think these folks work on glibc anymore. 8-)

For glibc, I think we will use nodiscard by default (outside non-fortify mode)
in most cases where we use __wur now (and some), and restrict __attribute__
((warn_unused_result)) to old compilers in fortify mode. Other libraries should
probably do the same. The __attribute__ ((warn_unused_result)) remaisn too
problematic because it encourages non-portable code to suppress it, such as
__attribute__ ((unused)).

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

[segher at gcc dot gnu.org]

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

--- Comment #51 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to rusty from comment #47)
> Civility please.

Thank you.

> As Andrew Pinski says "people are mis-using this attribute", and Jakub
> Jelinek makes a similar point.  The use of _wur has changed from "ignoring
> the result is criminally wrong" to "possibly wrong".

And that is the core of why this issue reinflames once in a while: some people
abuse the attribute, and the compiler cannot read minds.


The documentation of this attribute states
'warn_unused_result'
     The 'warn_unused_result' attribute causes a warning to be emitted
     if a caller of the function with this attribute does not use its
     return value.  This is useful for functions where not checking the
     result is either a security problem or always a bug, such as
     'realloc'.

The "non-bugs" section of the manual ("Certain Changes We Don't Want to Make"
says
   * Warning when a non-void function value is ignored.

     C contains many standard functions that return a value that most
     programs choose to ignore.  One obvious example is 'printf'.
     Warning about this practice only leads the defensive programmer to
     clutter programs with dozens of casts to 'void'.  Such casts are
     required so frequently that they become visual noise.  Writing
     those casts becomes so automatic that they no longer convey useful
     information about the intentions of the programmer.  For functions
     where the return value should never be ignored, use the
     'warn_unused_result' function attribute (*note Function
     Attributes::).

Completely useless casts to void cluttered programs decades ago already,
we do not fear cargo cult, instead we observed it already existed.

And finally there is
'-Wno-unused-result'
     Do not warn if a caller of a function marked with attribute
     'warn_unused_result' (*note Function Attributes::) does not use its
     return value.  The default is '-Wunused-result'.

A caller that casts a return value to void *explicitly* does not use that
return value.


> I still put a comment complaining about this every time I hit it, which is
> about once or twice a year.  But I have little more to say; it's been almost
> 20 year after all :)

Changing the behaviour of this attribute after all that time will not make
things better.  But perhaps we can say a bit more in the documentation,
maybe at one of the three very concise quotes above?  Say half a line worth?

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

[jengelh at inai dot de]

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

--- Comment #52 from Jan Engelhardt <jengelh at inai dot de> ---
>This is useful for functions where not checking the
>result is either a security problem or always a bug, such as
>'realloc'.

always? reall..y..oc?

  void *x = malloc(1);
  realloc(x, 0);

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

[achurch+gcc at achurch dot org]

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

--- Comment #53 from Andrew Church <achurch+gcc at achurch dot org> ---
(In reply to Segher Boessenkool from comment #51)
> And that is the core of why this issue reinflames once in a while: some
> people
> abuse the attribute, and the compiler cannot read minds.

Ah, for a mindread() API...

But ultimately, this is why I suggest that the compiler should leave as many
decisions as possible to the end user (in this case, the API user as opposed to
the API developer) - if the user has decided a particular result is safe to
ignore, then anything the compiler tries to do to stop that is just an
annoyance to be worked around or outright disabled.

> Completely useless casts to void cluttered programs decades ago already,
> we do not fear cargo cult, instead we observed it already existed.

At the risk of starting a linguistic discussion, the phrase you're looking for
is not "cargo cult", but "idiomatic".  Using "(void)" to mean "I am explicitly
discarding this value" is idiomatic, much the same way as "goodbye" is an
idiomatic greeting and not a literal wish for God to be with the listener.  I'm
probably not as old as some developers here, but I'm certainly old enough to
remember some compilers which gleefully spit out warnings on practically every
non-void expression, and liberal use of (void) was needed if you wanted any
chance at seeing the useful warnings.

"Cargo cult" programming is when people start using (void) without even knowing
what it does:  "Hey, so what does this 'void' thing do?"  "Uh, I dunno, it's
all over the code so I just copied it."  I wouldn't be surprised to find cases
of that as well, but I don't think that's the specific thing we're worried
about here.

> Changing the behaviour of this attribute after all that time will not make
> things better.  But perhaps we can say a bit more in the documentation,
> maybe at one of the three very concise quotes above?  Say half a line worth?

If glibc changes from _wur to [[nodiscard]], as Florian suggested may happen,
that would resolve the immediate case that brought me here (a "best-effort"
system() call, where the success or failure of the call or the program executed
is irrelevant to the caller).  I do fear leaving the current behavior as is
could just be kicking the can down the road, so to speak, but perhaps a slight
edit here might help:

> 'warn_unused_result'
>      The 'warn_unused_result' attribute causes a warning to be emitted
>      if a caller of the function with this attribute does not use its
>      return value.  This is useful for functions where not checking the
>      result is either a security problem or always a bug, such as
>      'realloc'.

I would suggest removing "either a security problem or", and adding something
along the lines of:

"For cases in which not checking the result carries risks but is not
necessarily an error, use the [[nodiscard]] attribute, which allows the caller
to suppress the warning by explicitly casting the result to void."

Writing user documentation isn't (remotely!) my specialty, but I think
something like this could both help clarify that the two behave differently and
let people know that yes, the fact that you can't silence _wur calls is
intentional.

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

[romato.san1337 at gmail dot com]

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

Roman Krotov <romato.san1337 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |romato.san1337 at gmail dot com

--- Comment #54 from Roman Krotov <romato.san1337 at gmail dot com> ---
I'm also very frustrated about this behavior, but I'm not asking to **change**
it. I see your point and, although I think it's severely outdated now, I
respect your decision.

Instead I'm offering a compromise, or to better describe it, a win-win
solution.
What about introducing something like `-Wno-void-unused`, which would only
disable the warnings for the (void) casted calls?

And I'm not asking to do it for me, or some other random dudes; do it for
systemd, they are also very frustrated about this:
https://github.com/systemd/systemd/blob/5a96b32dead5132ba37a8b968c59101c2aac8d23/meson.build#L400

That's because they use (void) casts very frequently:
https://github.com/search?q=repo%3Asystemd%2Fsystemd+language%3AC+%22%28void%29%22&type=code

You can probably say they are in the wrong by doing the bad practice and should
do a macro instead.
And you may be right. I really appreciate your commitment to teach people good
practices, but **suggesting** them (by setting the default behavior which
**recommends** the programmers to use these practices) should be enough.
I don't think it's a good idea to **force** people to use them, by either
spamming them with warnings (useless to them, because they already made a
decision) or making them disable such warnings altogether, which could lead
them to miss a bug where they forgot to use a value of a function (which they
didn't cast with void).

You may say it's their fault, but let me ask you a question, who is winning
from the current situation? Certainly, not you, because you didn't convince
them to change, instead you just made them not listen to you, see also
julia-language and mpv:
https://github.com/search?q=%22-Wno-unused-result%22&type=code

And certainly, not them, because of the bug-risk I typed above, which is really
unfortunate for such a big and widely-used project as systemd.
Also, making them switch to clang (or drop gcc support) would be really bad,
because nothing hurts FOSS and frustrates me in a project more than a
permissive license. Eww..

Sorry, if I was a little bit harsh there, I really appreciate your contribution
to FOSS and Linux development, and I would never switch to clang.
Just, please note, that, again, I'm begging you to just implement a non-default
switch that would make everyone's lives easier.

Why "everyone's"? You see,

If a new programmer encounters this "problem", they would think it's just a
"gcc bug", because "clang works as expected" (and also the mentioned projects
wrote like this in a comment), so they just disable the warnings altogether.
Nobody won, especially the programmer.
Now consider the situation where you implemented the switch, but wrote, for
example, in the manpage just that "It's not recommended". Now they will be
curious why, so they will try to find an answer, and the search will probably
lead them to the gnu.org page which has the answer.

See, how even though you might think you gave the ability to write a bad code,
in reality you would give the exact point why not to use (void)? (Which they
really need because other compilers/linters are trying to convince them
otherwise.)
Come on, at least please admit that the situation described above would still
be better than today's.

If you will find at least some of my points somewhat reasonable, please share
my comment with the people that can help bring this improvement to life.

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

[ed at catmur dot uk]

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

--- Comment #55 from Ed Catmur <ed at catmur dot uk> ---
(In reply to Roman Krotov from comment #54)
[[nodiscard]] is in C23, so we can expect that attribute to be adopted where
people intend that behavior (warning suppressible by cast to void) as opposed
to the nonportable [[gnu::warn_unused_result]] (warning not suppressible by
cast to void). So this problem will resolve itself, over time.

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

[muecker at gwdg dot de]

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

Martin Uecker <muecker at gwdg dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |muecker at gwdg dot de

--- Comment #56 from Martin Uecker <muecker at gwdg dot de> ---
[[nodiscard]] works as expected and is supported for older language modes since
GCC 11 (and the syntax is ignored with a warning in GCC 10). Clang supports it
with -std=c2x since version 9 and it seems Clang will also support it in older
language modes in future releases.

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

[romato.san1337 at gmail dot com]

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

--- Comment #57 from Roman Krotov <romato.san1337 at gmail dot com> ---
(In reply to Ed Catmur from comment #55)
> So this problem will resolve itself, over time.

But I don't see any reasons not to implement the switch right now...
Late is better than never.

> we can expect that attribute to be adopted where people intend that behavior
> as opposed to the
> warning not suppressible by cast to void

I see your point and I partially agree with it, but what about the projects
what don't agree with the distinction of these 2 attributes? Or just want to be
more compatible with clang?
Or they just may not agree with the choice of a library, that decided to put
wur instead of nodiscard for a specific function.
Something like -Wno-void-unused would still be better for them than
-Wno-unused-result, for the reasons in my previous comment.

(In reply to Martin Uecker from comment #56)
> works as expected and is supported for older language modes

Even if one day projects, that will prefer to stay on C99 or C11 and use
-Wpedantic (which warns about [[]] right now), will be able to use [[syntax]]
without any warning, they may still not like it. Even if gcc will include
nodiscard into the __attribute__ syntax, there, for sure, will be the libraries
that won't prefer to update or use the new attribute.
For these situations, or even if they **will** use the new attribute, see my
previous paragraph.

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

[ed at catmur dot uk]

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

--- Comment #58 from Ed Catmur <ed at catmur dot uk> ---
(In reply to Roman Krotov from comment #57)
> But I don't see any reasons not to implement the switch right now...
Making [[gnu::warn_unused_result]] mean the same as [[nodiscard]] would be a
reduction in expressivity.

> what about the projects
> what don't agree with the distinction of these 2 attributes? Or just want to
> be more compatible with clang?
They can use [[nodiscard]].

> Or they just may not agree with the choice of a library, that decided to put
> wur instead of nodiscard for a specific function.
Then they can write their own wrappers using [[nodiscard]].

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

[romato.san1337 at gmail dot com]

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

--- Comment #59 from Roman Krotov <romato.san1337 at gmail dot com> ---
(In reply to Ed Catmur from comment #58)
> (In reply to Roman Krotov from comment #57)
I already addressed all of it in my previous 2 comments...
I'll write more clearly then.

> > But I don't see any reasons not to implement the switch right now...
> Making [[gnu::warn_unused_result]] mean the same as [[nodiscard]] would be a
> reduction in expressivity.
All, what I'm asking for, is to make something like -Wno-void-unused, which
would suppress the warnings only for the (void) casted calls.
This is desperately needed by the projects like systemd (see the first link in
my first comment) as a less severe variant than -Wno-unused-result, so that
they won't get punished with less diagnostics.

In fact, gcc already has a "not recommended non-default" switch model:
  -Wno-coverage-mismatch
    <...>   -Wno-coverage-mismatch  can  be  used  to  disable  the warning
<...> disabling the warning is not recommended.

I don't see any reason not to implement -Wno-void-unused with the similar
description (stating that it's not recommended, if you want) to help the
projects like systemd.
It won't change the meaning of the wur attribute, bacause it will be a
non-default switch.

> > what about the projects
> > what don't agree with the distinction of these 2 attributes? Or just want to
> > be more compatible with clang?
> They can use [[nodiscard]].
> 
> > Or they just may not agree with the choice of a library, that decided to put
> > wur instead of nodiscard for a specific function.
> Then they can write their own wrappers using [[nodiscard]].
What about libraries and programs that will prefer to stay on C99/C11 (without
C2x extensions), especially if they use -pedantic?
Even if there will be something like __attribute__(nodiscard),
What about programs and libraries that will not prefer to update?
That's why we shouldn't rely on the future and should implement the solution
now.

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

[segher at gcc dot gnu.org]

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

--- Comment #60 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Roman Krotov from comment #59)
> All, what I'm asking for, is to make something like -Wno-void-unused, which
> would suppress the warnings only for the (void) casted calls.

So you want to not warn for some (just *some*) explicitly unused cases, and do
warn for other explicitly unused cases, and all implicitly unused cases?  While
the author of the code explicitly asked for a warning message to be emitted in
all such cases: "The 'warn_unused_result' attribute causes a warning to be
emitted if a caller of the function with this attribute does not use its return
value."

> This is desperately needed by the projects like systemd (see the first link
> in my first comment) as a less severe variant than -Wno-unused-result, so
> that they won't get punished with less diagnostics.

They (like EVERYONE ELSE IN THE WORLD) should not use -Werror, if they do not
like punishment.  Warnings are warnings.  The author of your code (the header
files for the library code) wanted everyone to be warned about not using the
return value from a certain function.  He/she was almost certainly right about
that.  And it is easy to suppress the warning in the few cases where you really
want to.

> I don't see any reason not to implement -Wno-void-unused with the similar
> description (stating that it's not recommended, if you want) to help the
> projects like systemd.

Define what it would do *exactly*, make a patch for it (including for the
documentation, amending all existing documentation as well), and do that in
such a way that it a) is correct, and b) makes any sense.  Then send the
patch to gcc-patches@.  If you do not want to do all that work (including the
very much non-trivial amount of follow-up work that will cause), then please
go away?  Don't tell us to do insane things that are an incredible amount of
work just because you had a bad idea and now want it to become reality.

> It won't change the meaning of the wur attribute, bacause it will be a
> non-default switch.

This makes no sense at all.

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

[achurch+gcc at achurch dot org]

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

--- Comment #61 from Andrew Church <achurch+gcc at achurch dot org> ---
For the record, I'll maintain a copy of my (unaccepted) patch to add
-Wunused-result=strict at: https://achurch.org/patch-pile/#gcc
(wur-strict.diff)

This flag obviously shouldn't be relied on in released packages, but it may be
helpful for individual users trying to work around this issue.

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

[groessler_christian at yahoo dot de]

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

Christian Groessler <groessler_christian at yahoo dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |groessler_christian at yahoo dot d
                   |                            |e

--- Comment #62 from Christian Groessler <groessler_christian at yahoo dot de> ---
(In reply to Segher Boessenkool from comment #60)
> So you want to not warn for some (just *some*) explicitly unused cases, and
> do
> warn for other explicitly unused cases, and all implicitly unused cases? 
> While
> the author of the code explicitly asked for a warning message to be emitted
> in
> all such cases: "The 'warn_unused_result' attribute causes a warning to be
> emitted if a caller of the function with this attribute does not use its
> return
> value."

Yes! I'm write()ing to a pipe a small amount of data (< page size), and anyway
don't know how to continue if the write() fails. It would be noticed at the
other end.

(void)write(....)  doesn't suppress the warning. Annoying...