Gert Wollny <gw.foss...@gmail.com> writes: >> To directly answer your question, since I think everyone so far has told >> you that you should fix it, this answer from S/O [1] >> > [...] >> [1] >> http://stackoverflow.com/questions/3614691/casting-to-void-doesnt-remove-warn-unused-result-error/3615000#3615000
> One should note that the question on S/O was about opening "/dev/null" > which is unlikely to fail. Less unlikely than one might think. I've seen this fail in several situations, usually because the program is being run in a partial chroot, but on one occasion because someone deleted the device. In the latter case, /dev/null later became a regular file because some program was opening it with O_CREAT (aie), and that caused all sorts of truly bizarre problems. It's sometimes the case that errors really don't need checking, but more rarely than people think. Good software needs error handling mechanisms for unusual failure conditions. If you really think that this should never fail, check the return status with assert(). That way, if the impossible happens, at least you terminate the process rather than continuing under false assumptions. The only exception I've run into for this particular warning in my own code was in monitoring software that was speaking the IMAP protocol. It sent a "tag logout" command to the server before closing the socket, but it truly, absolutely did not care if that write failed, since the correct action to take if the write failed was to... close the socket. Sending the logout command was just being polite to the server. In that case, I used the following construct: /* Only for clean shutdown, don't care about failure. */ if (socket_write(sd, "tag logout\r\n", 12) < 0) {} socket_close(sd); which gcc is happy with. (The socket_* calls are, on Linux, just macros that expand to write and close. They exist for compatibility with Windows, where different functions have to be used when working with sockets.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wql4m0b3....@windlord.stanford.edu