Re: [libvirt] [RFC PATCH] build: avoid %zu in translated strings
[re-adding bug-gnulib for another question]
On 08/18/2010 07:51 AM, Daniel P. Berrange wrote:
On Wed, Aug 18, 2010 at 07:41:16AM -0600, Eric Blake wrote:
> On 08/18/2010 03:04 AM, Daniel P. Berrange wrote:
>>
>> I find the PRI* stuff rather fugly. Can't we just use %llu and
>> cast to (unsigned long long)
>
> Unfortunately, %llu is equally non-portable to mingw. And yes, we also
> have some %llu encoded into translated strings, which would also need help.
>
>>
>> The question of printf-posix license doesn't appear relevant since
>> remoteError & friends all use asprintf() which is LGPLv2+ already.
>
> 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+.
Hmm, that's odd, because support for %llu in printf was one of the
primary reasons we started using GNULIB in the first place. We have
been relying on %llu working, throughout the code.
Bruno, is my understanding of the differences between vasprintf and
vasprintf-posix correct? If so, it means that gnulib is already in the
situation that the bulk of the source code to support %zu and %llu is
available via the vasprintf module, but hidden behind #defines that are
not supplied unless you use the LGPL vasprint-posix module. But the
vasprintf-module only adds .m4 files on top of the existing mix of
vasprintf files, and there is nothing about the .m4 files that must be
LGPLv3+ only (since they already have a more permissive license).
On the surface, it seems like I could technically copy the contents of
the vasprintf-posix .m4 files (since they are already a more permissive
license) and couple that with the existing LGPLv2+ vasprintf module, all
without violating any licensing. Looking a bit closer, though,
vasprintf-posix drags in some new LGPLv3+ dependencies, like isnand-libm
and printf-frexp; but even then, if I'm willing to link with -lm on
mingw and avoid %a and %Lg, it seems like I can avoid those extra
dependencies.
Still, I'm reluctant to bite the bullet and go with the LGPLv2+ cascade
on vasprintf-posix. So maybe the solution is an intermediate module:
LGPLv2+ vasprintf - bare bones, guarantees a wrapper around system
printf, so %zu and %llu are unsafe because of mingw
LGPLv2+ vasprintf-sizes - guarantees %zu, %llu, %ju, %tu; but not %Lg
(which means splitting gl_PRINTF_SIZES_C99 into two) or %'d
LGPLV3+ vasprintf-posix - guarantees full contingency of POSIX specifiers
If this three-level proposal makes sense, then I can start on the work
of extracting the simpler portions of vasprintf-posix into the new
vasprintf-sizes.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)