Fix format strings

[rikardfalkeborn]

This is a series of commits cleaning up format specifiers for the curl_*printf functions as a preparation for the last commit where an attribute is added to show which arguments are the format string, and which are the format specifiers.

A few comments on some of the commits:

tests: Fix format specifiers - In unit1323.c, the exact types for the members of the timeval struct is not specified, perhaps I should have added a cast to avoid protential problems on other platforms?

Make sure format length is int - Apparently, the standard says field precision specifiers should be of type int. I just added a cast to the variables. I have no idea if there's a risk it will overflow or wrap...

Add attribute to teach Gcc about printf-functions - A big bummer is that curl printf extensions (such as %.-2f) now gives warnings). I was not able to figure out if there was a way tell gcc about these extensions. It also means anyone using curl/mprintf.h with nonstandard extensions will get a warning.

[bagder]

This pull request introduces 2 alerts when merging 1dce353 into c3d7db4 - view on lgtm.com

new alerts:

• 2 for Wrong type of arguments to formatting function

---

Comment posted by lgtm.com

[rikardfalkeborn]

No surprise CI found a number of issues I didn't spot for different configurations/etc. I'll try and fix these and update the PR.

[rikardfalkeborn]

It seems travis builds spews out warnings about ISO C90 does not support the ‘z’ gnu_printf length modifier which curl/lib/mprintf.c does support. I suppose I should drop the attribute commit (and the format specifier one). And perhaps even split the PR in smaller ones?

[bagder]

Thanks for your work!

It seems travis builds spews out warnings about ISO C90 does not support the ‘z’ gnu_printf length modifier which curl/lib/mprintf.c does support.

Yeah, I was afraid exactly something like this would happen. The curl printf() code is not exactly like the C90 one.

I suppose I should drop the attribute commit (and the format specifier one).

I'm afraid I think that might be the only solution that doesn't force us to do other ugly things to avoid those warnings. Your work still identified a number of improvements thanks to that!

And perhaps even split the PR in smaller ones?

Nah, I'm fine with having "fixing printf() modifiers" being a single one etc.

[bagder]

thanks!