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

[Xiaobin Lu]

FYI, I've filed bug 6781583 to address this, there are also some casts 
problems when doing compilation on 64 bit platforms.  I agree it is ugly 
to use a unused local variable to make the aggressive compiler happy, 
but I don't find other options  such as pragam etc to get around this. 
Luckily, we don't have many of these except for a few fwrite and write 
calls, so it is not so bad to just put unused variables there ( I would 
also put a comment to tell why it is there.)

-Xiaobin

David Holmes - Sun Microsystems wrote:
> 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.
>>>