[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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list