Re: [libvirt] [RFC PATCH] build: avoid %zu in translated strings

On 08/18/2010 03:04 AM, Daniel P. Berrange wrote: Unfortunately, %llu is equally non-portable to mingw. And yes, we also have some %llu encoded into translated strings, which would also need help. We use the 'vasprintf' module, which is indeed LGPLv2+, but it does not guarantee the existence of %llu nor %zu -- it only guarantees that you have the [v]asprintf wrappers around your current system's (non-)compliant printf family, so it inherits the same bugs regarding unsupported specifiers. We would have to use the vasprintf-posix module to get %zu, but that module is LGPLv3+. One other potential solution: most (all?) of our translated strings involve error messages, and are therefore already funneled through our virterror.c implementation. As long as a string containing %zu or %llu is never directly handed to printf, but is guaranteed to go through virterror.c, then it would be possible to have virterror.c do some #ifdef magic such that on all sane platforms, the %zu and %llu are used unchanged (no extra overhead required); but on broken platforms (aka mingw), %zu and %llu are translated at runtime to %lu or %I64u (the %zu translation depends on whether you are 32-bit/64-bit mingw, and the 64-bit translation relies on microsoft's non-standard format specifier). This solution would then confine the ugliness to one file, such that the rest of libvirt can use %zu and %llu at will. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org