[Bug 305176]

[Manu-gcc]

(In reply to Manuel López-Ibáñez from comment #33)
> (In reply to Manuel López-Ibáñez from comment #32)
> > (In reply to Filipe Brandenburger from comment #31)
> > > gcc should catch up.
> > 
> > I thought Google employed some capable C/C++ engineers...
> 
> What I meant is that those engineers, if they exist, could help GCC "catch
> up" (whatever that means)... gcc does not develop itself or by magic gnomes,
> you know.

Hum, that still sounds worse than it sounded in my mind. Sorry, I'm
dense this morning :)

Just: help us, we love you, let's make the world a better place together
:)

(deleting comments in bugzilla would be helpful sometimes).

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-defaults in Ubuntu.
https://bugs.launchpad.net/bugs/305176

Title:
  [PR25509] can't disable __attribute__((warn_unused_result))

Status in GLibC:
  Fix Released
Status in gcc-defaults package in Ubuntu:
  Fix Released
Status in glibc package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: gcc

  This might be in one of the libs, but the problem is fundamentally in
  gcc.

  There is a recent attribute (warn_unused_result) that has been applied
  to nearly every function that isn't declared a void.  This includes
  things like write and fwrite (and even fread and read).  So many
  programs that compiled cleanly now spew forth pages of errors.

  THERE IS NO WAY TO DISABLE THIS WARNING.  Either from CFLAGS or with
  anything simple like a cast.  [This is not the case; -U_FORTIFY_SOURCE
  disables it, as does if (write(...)) {}, the latter of which could
  easily be turned into a macro if desired. -cjwatson]

  With the pages of new warnings, it is hard to find real errors or
  warnings about significant things.

  In most cases the ignoring of the return value is intentional - in the
  case of the read, it is for an echo which I know will occur from a
  device - the write will fail if the device detaches, but I need to
  wait for the echo before the close - which I would do anyway if the
  read failed.  For most writes, they are also "fire and forget" and an
  actual problem will be caught at some point - having a chain of 20
  writes (including logging and stderr) - it is unlikely that just one
  in the middle will fail.  Or they are clean shutdown that an exit(x)
  would handle less gracefully.  Others would only error on
  SIG_ARMAGEDDON or SIG_MAGIC cases where a cosmic ray has flipped a bit
  in ram somewhere or the CPU is overheating or some other problem which
  is both unlikely and there is no good way to handle it.

  There is also no pedantic_warn... or Wall_warn variants where this
  might be appropriate for these middle cases - I do turn them on
  occasionally to verify the code.  (Things like signed-unsigned
  conversions or comparison are in this class - often I know the range
  is limited so the code will work).

  And the warning is appropriate for almost every call that does return
  significant information.

  One that doesn't seem to have it is printf, but it seems neither does
  fprintf, and it is just a formatter over fwrite which I think does
  have this attribute (and will succeed - to the buffer, fflush might
  expose an error condition).

  Since there are lots of libraries with lots of different authors (and
  I think the syscalls which would include write are part of gcc), the
  easier fix is to lower this warning below default (to -Wall or
  -pedantic), or at least provide a -no-warn-unused-result option.  For
  completeness a secondary attribute equivalent to warn_unused_result
  that only prints a warning when -Wall or -pedantic is used can be
  added to GCC so we could have the best of both worlds.

  Or run the body of ubuntu universe or the 18k debian packages and see
  which functions are commonly affected and quiet the warnings on very
  common cases in the originating library header file (remove or modify
  the attribute), e.g. write, and I think fwrite, but there may be many
  others I don't know about where ignoring a return value is common
  practice and is not bad technique.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/305176/+subscriptions