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
