Hi Scott, Scott Cheloha wrote on Sat, Jul 22, 2017 at 11:27:17AM -0500:
> Okay, going back and rereading, it appears he meant specifically to not > (void) stuff like printf or fprintf, e.g. > > (void)fprintf(stderr, "usage: prog [args]\n"); /* don't do this */ Even on printf(3), (void) may occasionally make sense, for example when using %ls or %lc with a user-supplied string, in which case you normally have to check that the return value and be wary of EILSEQ, which almost everybody always forgets. But not in the case you quote above, of course. > My (maybe unfounded) concern is that the (void) cast doesn't > necessarily signal the same thing to everyone. There are more than two levels of obviousness. When it's obvious that ignoring the return value makes sense, don't put anything. When an auditor might think that ignoring the return value might possibly be a bug and is in danger of wasting time to investigate, and you *have* audited the call and are sure it is OK, and it is obvious what type of potential bug is involved, just put (void). If it is not even obvious what the call needs to be audited for and a mere (void) would be ambiguous, write an explicit comment in addition to the (void) cast. That is rarely needed, though. > The preponderance of (void) casts on stuff like memcpy > and fprintf seems to confirm this. I guess most (void)close() out there is just cargo cult or compiler bootlicking. Yours, Ingo
