On 01/30/2012 12:15 PM, Marc-André Lureau wrote:
> But we can use 'lld' because we made sure all libvirt
code goes
> via the gnulib printf replacements which guarentee %lld works
> correctly.
Actually, it doesn't. The replacement is provided by the module
"stdio" which isn't used (or perhaps indirectly?).
Rather, the replacement is provided by the snprintf, vasprintf, and
vsnprintf, modules. As long as we go through one of those three
functions, we should be getting the GNU signature of %lld, and NOT the
mingw signature of %I64d. If we fail to go through one of those three
functions (such as a raw printf), then we have to use the common subset
that is supported by both gnu and mingw.
But even if it was
used, it wouldn't be the POSIX version using gnuprintf format, it
would be the "system" one. If we want the former, we would need
"fprintf-posix" module, unfortunately, it seems to have incompatible
licenses:
No, we intentionally do NOT want to use the native format. Anywhere
that we are calling a *printf that has not gone through a gnulib module,
we have a bug in libvirt.
However, it would only solve the fprintf() call, not the fscanf() call
which doesn't have equivalent "fscanf-posix" yet.
Correct, calls to fprintf are buggy, and fscanf is a disaster that
should be using virStrToLong_* instead.
An alternative to avoid casting everywhere is to use a couple of
helper functions to do the job of:
fprintf(file, "%" PID_FORMAT, pid) and fscanf(file, "%" PID_FORMAT,
pid) which I guess could be replaced by virFprintfPid() and
virFscanfPid(). Agree?
Those helper functions are precisely what the gnulib module snprintf and
friends _already_ should be giving us. We just have to use them correctly.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org