neovim/neovim — pull request #574 by elmart (2014-04-20 19:01:21+00:00)
Title: [WIP] Use portable format specifiers

I've given #490 a try.

What I've done is:
- Replace "%lld" and "%ld" within printf format string with '"%" PRId64'.
- Cast corresponding argument to (int64_t).
- In *.po files, use corresponding "%" facility.

I've used casting because from what I read at #490 and #296, I understood the
task of converting those arguments to real (int64_t) type is considered another
task, for which this one is a prerequisite.

For ease of review, I've subdivided commits by function invoked (sprintf,
vim_snprintf, etc.) and by localization (whether the format string gets
localized before invoking printf-like function).

This passes all tests on my machine, but I'm on 64 bits.
I think this will fail on 32 bits, but only because of a last thing that remains
to be done: fixing the vim propietary implementation of snprintf/vsnprintf. This
is:

- Vim implements its own portable version of snprintf/vsnprintf. See
https://github.com/neovim/neovim/blob/master/src/message.c#L3086
- That implementation doesn't support 'll' length specifier. See
https://github.com/neovim/neovim/blob/master/src/message.c#L3104.
- Which is a bit weird, since the original code at
http://www.ijs.si/software/snprintf/ does support 'll'.

So, we can:

- Fix vim own implementation of snprintf/vsnprintf.
- Remove it alltogether and use system version of those functions. It is
supposed that, in C99 that we are targeting, those should be supported by all
major compilers/platforms.

I'm not sure about Vim's motivation to adapt code from
[http://www.ijs.si/software/snprintf/]. In particular, why leaving out support
for 'll' if it was there? Is there some reason we don't know for that?

Also, although system-level snprintf/vsnprintf are supposed to be available in
C99, I don't know if that's really that way or if it poses serious problems in
practice. I've found contradictory opinions in the web regarding that.

So, what do you think?