I agree that this warning is sometimes excessive and inconvenient,
particularly for logging writes which are, as you put it, "fire and
forget".
Notwithstanding that, though, I would note that it *is* good practice to
check non-logging writes. Contrary to popular belief, write() is not
guaranteed to write everything you give it, and it doesn't take
particularly unusual circumstances to cause it not to do so: if your
code might ever be interrupted by a signal (for example if it uses
subprocesses, or is a daemon that might be reloaded using SIGHUP, or all
sorts of other situations), then write() can write less data than you
asked for. This change *has* exposed a lot of real reliability bugs that
we needed to fix anyway.
It seems particularly unfortunate that a (void) cast does not silence
this warning. You can, however, do this:
if (write(...)) { }
** Description changed:
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.
+ 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.
--
[PR25509] can't disable __attribute__((warn_unused_result))
https://bugs.launchpad.net/bugs/305176
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
