On Sat, May 29, 2010 at 3:16 AM, Dave Korn <dave.korn.cyg...@gmail.com> wrote: > 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?
Yes. Please file a bugreport (and first check the proposed workaround really works..). Richard. > cheers, > DaveK > > >
