tools/fnt2bdf: fix a few compiler warnings (1/10)
mstefani at redhat.com
Sun Nov 16 06:19:43 CST 2008
Marcus Meissner wrote:
> On Wed, Nov 12, 2008 at 10:28:37AM +0100, Michael Stefaniuc wrote:
>> Austin English wrote:
>>> This series of patches fixes most of the new warnings generated in gcc
>>> 4.3.2. There's one issue left, but I'm not quite sure what should be
>>> done on that one.
>>> diff --git a/tools/fnt2bdf.c b/tools/fnt2bdf.c
>>> index 1a14d6c..3c3134b 100644
>>> --- a/tools/fnt2bdf.c
>>> +++ b/tools/fnt2bdf.c
>>> @@ -595,14 +595,14 @@ int main(int argc, char **argv)
>>> if( !(lpfont = (unsigned char*) realloc( lpfont, length )) )
>>> - fprintf(stderr, errorMemory );
>>> + fprintf(stderr, "%s", errorMemory );
>> Ugly. You could just use fputs instead.
>> But if you know that the passed in strings are safe aka no format
>> specifiers in them you can leave the code as is as the compiler warning
>> is bogus.
> Well, gcc will optimize fprintf(X,"%s",Y) to fputs(X,Y) (and some other funny
You mean to fputs(Y,X) ? That's my gripe with fputs that it has a
different order of arguments than fprintf.
> stuff when errorMemory is known and constant).
Sure, the compiler will do a lot of stuff but what it cannot do is
improve readability of the code. If one means "write the string out
unmodified" then fputs is a better choice as it makes the intention
> But I disagree with leaving it in as-is ...
Well the error strings are really just static const strings declared at
the top of the file. So the code is *correct* and the gcc warning is
> It is sloppy coding and might lead to later problems when used cut&pasted.
I don't feel strongly about this. But if it gets replaced it should use
a construct that better expresses the intent.
More information about the wine-devel