libvirt is currently LGPLv2+, but needs to use the printf family of
functions to display size_t values, even on mingw where %zu support is
not built in. My understanding is that on 64-bit windows,
sizeof(long)==4 but sizeof(void*)==8; and if I'm reading
http://msdn.microsoft.com/en-us/library/s3f49ktz%28VS.80%29.aspx
correctly, then sizeof(size_t) is also 8. Which means you _can't_ use
"%lu",(unsigned long)size_t_val. And mingw also lacks support for
"%llu",(unsigned long long)size_t_val.
So that leaves several options:
Is it worth relaxing the license on the *printf-posix family of modules
to LGPLv2+ from their current LGPLv3+, or is this too big of a request?
Ultimately, this is the nicest - %zu would just work.
Is it worth relaxing the license of the inttostr family of modules?.
But that is also LGPLv3+, and requires a more careful audit to convert
all uses of "%zu",size_t_val into "%s",umaxtostr(size_t_val,buf).
Or,
since using umaxtostr penalizes 32-bit machines for converting to the
64-bit intermediary, maybe it's worth adding a size_t variant? That,
and coreutils has a TODO to remove use of umaxtostr in favor of
<inttypes.h> solutions.
Finally, within existing LGPLv2+ modules, it is possible for libvirt to
manually use "%"PRIuMAX,(uintmax_t)size_t_val everywhere by relying on
gnulib's <inttypes.h> replacement, but that's also a painful audit to
perform and maintain, and also wastes processor cycles on 32-bit
machines for converting to the 64-bit intermediary.
What a shame that POSIX omitted an <inttypes.h> PRIu* for size_t.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org