On 29/05/2010 01:14, Ian Lance Taylor wrote: > Dave Korn <dave.korn.cygwin@ writes:
>> there is *no* circumstances >> under which ignoring the return from *any* function is *always* a bug. > For practical purposes, it is always a bug to ignore the return value > of realloc (I disregard the unusual case of passing 0 as the second > argument in order to free the memory block). Also the case of calling it for a size that is known a priori to be less than the original size of the block! > We could certainly decide that we don't care about that fine > distinction, and just fall back to the weaker definition which permits > easy overriding with a cast to void. But we shouldn't do it on the > basis that the current definition does not make sense. We should only > do it on the basis that the current definition is not worth > preserving. I guess that's what I'm having a hard time being convinced of. It seems to me that for most of the warnings we provide, we have a mechanism to allow users to disregard them in system headers. What it really is is, I don't see the consistency in disregarding an explicit cast to void, yet permitting a workaround such as an inlined no-op function that casts the parameter to void. Isn't that just a bug, that it fools the warning, and it ought to be fixed? cheers, DaveK