On Wed, Aug 18, 2010 at 09:54:51AM -0600, Eric Blake wrote:
> On 08/18/2010 08:30 AM, Eric Blake wrote:
> > 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.
>
> Actually, after looking into this deeper, it (happily) appears that I
> may have been mistaken. It looks like the gnulib vasprintf module
> _already_ performs printf parsing on mingw; and that as a virtue of that
> printf parsing, %zu and %llu are already rewritten into modifiers
> understood by mingw. I tested this by modifying test-vasprintf.c to try
> %zu and %llu on a mingw compilation, and the test still passed.
>
> The gnulib module snprintf will likewise support %zu and %llu, but only
> if it is in use (right now, libvirt is not using the snprintf module).
>
> However, there is no counterpart printf or sprintf, but libvirt uses
> those functions as well. So there is still some work to be done in
> libvirt to make sure all *printf() family calls eventually end up going
> through gnulib wrappers, to take advantage of the fact that gnulib's
> vasprintf _is_ sufficient to support %zu and %llu on mingw.
Do we actually have any places where printf/sprintf hurts ?
I see nothing using %zu
# find -name '*.c' | xargs grep -i printf | grep -i -v asprintf | grep -v virBuffer | grep -v gnulib | grep '%z'
And just a handful of things using %ll
$ find -name '*.c' | xargs grep -i printf | grep -i -v asprintf | grep -v virBuffer | grep -v gnulib | grep '%ll'
./src/storage/storage_backend.c: snprintf(size, sizeof(size), "%lluK", vol->capacity/1024);
./src/storage/storage_backend.c: snprintf(size, sizeof(size), "%llu", vol->capacity/1024/1024);
./src/storage/parthelper.c: printf("%s%s%d%c%s%c%s%c%llu%c%llu%c%llu%c",
./src/storage/parthelper.c: printf("%s%c%s%c%s%c%llu%c%llu%c%llu%c",
./src/storage/storage_backend_disk.c: snprintf(start, sizeof(start)-1, "%lluB", startOffset);
./src/storage/storage_backend_disk.c: snprintf(end, sizeof(end)-1, "%lluB", endOffset);
./src/storage/storage_backend_logical.c: snprintf(size, sizeof(size)-1, "%lluK", vol->capacity/1024);
./tests/qemuhelptest.c: fprintf(stderr, "Computed flags do not match: got 0x%llx, expected 0x%llx\n",
./examples/domain-events/events-c/event-test.c: printf("%s EVENT: Domain %s(%d) rtc change %lld\n", __func__, virDomainGetName(dom),
All these are code modules which are Linux specific, though arguably we
should kill the snprintf() in favour of virAsprintf() for sanity sake.
Everything else ends up routed via vasprintf so, I think it is sufficient
for libvirt to just use vasprintf and not worry about the printf/snprintf
issue (at least not urgently)
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list