tools/fnt2bdf: fix a few compiler warnings (1/10)

[Michael Stefaniuc]

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

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

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

bye
	michael