"Vakatov, Denis (NIH/NLM/NCBI) [E]" <vaka...@ncbi.nlm.nih.gov> writes:
> Ian Lance Taylor wrote: > >> We should handle must_use_result and warn_unused_result similarly, except >> that adding a cast to (void) disables the warn_unused_result warning. >> Perhaps there should also be other simple ways to disable the >> warn_unused_result warning. >> >> This is not a great solution, but I don't see a better way out of the >> current unpleasant situation. > > You seem to be looking for an absolute solution, and there is > none. You can't do it all on the GCC side alone. Yes, of course. That was implicit in my suggestion. > The reasonable (or, "great enough") solution would be to just trust > explicit developer's void-casting. > > Also, 'warn_unused_result' should be enough; there is no need to add > more levels to this simple paradigm. The warn_unused_result extension was implemented specifically to catch security problems. Permitting developers to just add a cast to void would make it a very weak facility. Of course in one sense we should trust the developer. But the history of security problems shows that developers can not always be trusted. Instead, we assume that there at least one trusted developer who can add warn_unused_result when appropriate. Then the compiler arranges matters such that other developers can not easily avoid the warning. Thus security is, ideally, increased. Unfortunately this hasn't worked in practice, because glibc and Debian have combined to make many reasonable compilations, which have no security issues, run afoul of warn_unused_result. So my proposal is to change the existing facility to make it be what glibc and Debian really want, and to provide a new facility which does what warn_unused_result was originally intended to do. I would interpret your suggestion as being that we should abandon the security goals of warn_unused_result, and settle for the weaker version which glibc and Debian seem to want. Perhaps that is the correct way to go. But it does not seem so to me. Ian
