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

[Kelly O'Hair]

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.
>