On Thu, Jan 26, 2012 at 11:28 AM, Daniel P. Berrange
<berrange(a)redhat.com> wrote:
On Wed, Jan 25, 2012 at 05:54:19PM -0700, Eric Blake wrote:
> On 01/25/2012 05:22 PM, Marc-André Lureau wrote:
> >> the decision should _not_ be based on _WIN64, but instead on a
> >> configure-time test on the underlying type of pid_t. And since
> >> _that_
> >> gets difficult, I'd almost rather go with the simpler approach of:
> >>
> >> "%" PRIdMAX, (intmax_t) pid
> >>
> >> everywhere that we currently use
> >>
> >> "%d", pid
> >>
> >
> > I thought about using that solution, but I prefer the format macro.
> > Tbh, I wish some of these would be part of gnulib (perhaps some already are).
>
> Sadly, no one has made a case for extended type macros in gnulib. And
> mingw points out the problem - we can't use "lld" nor PRIdMAX for
pid_t,
> since we don't know whether the code is targetting gnu printf, windows
> printf, or a mix. I really do think we're stuck with casting to (long
> long) or (intmax_t) in this case :(
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?). 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:
.gnulib/gnulib-tool: *** incompatible license on modules:
fpieee LGPL
fprintf-posix LGPL
fpucw LGPL
frexp-nolibm LGPL
frexpl-nolibm LGPL
fseterr LGPL
isnand-nolibm LGPL
isnanf-nolibm LGPL
isnanl-nolibm LGPL
printf-frexp LGPL
printf-frexpl LGPL
printf-safe LGPL
signbit LGPL
However, it would only solve the fprintf() call, not the fscanf() call
which doesn't have equivalent "fscanf-posix" yet.
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?
--
Marc-André Lureau