Hi ----- Mensaje original ----- > Also, I'm not quite convinced on your approach. While it's nice to > hide > the type behind a macro: > > > > +#ifdef _WIN64 > > +/* XXX gnu_printf prefers lld while non-gnu printf expect > > PRId64... */ > > Libvirt should not be using non-gnu printf. What function call gave > you > that warning, so that we can fix it to use gnu printf? They come from fprintf and fscanf here: util/virpidfile.c: In function 'virPidFileWritePath': util/virpidfile.c:72:5: warning: unknown conversion type character 'l' in format [-Wformat] util/virpidfile.c:72:5: warning: too many arguments for format [-Wformat-extra-args] util/virpidfile.c: In function 'virPidFileReadPath': util/virpidfile.c:130:5: warning: unknown conversion type character 'l' in format [-Wformat] util/virpidfile.c:130:5: warning: too many arguments for format [-Wformat-extra-args] > > +# define PID_FORMAT "lld" > > +#else > > +# define PID_FORMAT "d" > > +#endif > > 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). glib also has a bunch of these, although not pid_t. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list