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

[Eric Blake]

[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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature