fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1

[David Holmes - Sun Microsystems]

I don't know who is most at fault here: the glibc folk for marking these 
methods with an attribute that forces a warning to always be issued 
regardless of what the developer writes in his code, or selects for her 
compiler options; or the gcc folk for providing such an attribute in the 
first place. :-( Too much hand-holding if you ask me.

But having to store into an unused local to get around this is plain absurd!

David Holmes

Kelly O'Hair said the following on 12/05/08 07:42:
> It's a quality of the compiler implementation issue.
> I know there are no formal standard violations here, but the
> intent of an explicit void cast has always been clear.
> 
> -kto
> 
> Andrew Haley wrote:
>> Kelly O'Hair wrote:
>>> Both fwrite() and (void)fwrite() are legal,
>>> the first one is a potential error, but the later
>>> is defined by the standard as having the function return value
>>> explicitly "discarded".
>>
>> The standard doesn't distinguish between them.  Both are evaluated
>> as void expressions.
>>
>>> So warning about a value that has been explicitly "discarded" by
>>> the terms of the standard seems like a very questionable warning.
>>
>> Perhaps so, but that is nothing to do with standards conformance,
>> which you were questioning.  Let me be clear: a C compiler is allowed
>> to warn about anything at all, as long as every standard program is
>> executed according to the rules of the abstract machine.
>>
>> Andrew.
>>
>>
>>> Andrew Haley wrote:
>>>> Kelly O'Hair wrote:
>>>>> The issue seems so simple to me.
>>>>> If the function return is to be ignored, you make an explicit cast
>>>>> to void. This practice is so old and common I don't understand why
>>>>> it's so complicated.
>>>>> gcc/g++ are not the only compilers on the planet.
>>>>> Writing portable C or C++ code becomes increasingly more complicated
>>>>> when you have to rely on special features of the compiler to get them
>>>>> to shut up about perfectly valid code.
>>>>>
>>>>> What happened to following the standards?
>>>>>
>>>>> WG14/N1124 6.3.2.2 void
>>>>>
>>>>> "... If an expression of any other type is evaluated as a void
>>>>> expression, its value or designator is discarded.
>>>>> (A void expression is evaluated for its side effects.)"
>>>> Huh?  The standard doesn't say that you should not warn about
>>>> legal but potentially problematic code.  That's what most
>>>> warnings are, after all.
>>>>
>>>> Andrew.
>>