| Message ID | 1333130099-25238-1-git-send-email-aliguori@us.ibm.com |
|---|---|
| State | New |
| Headers | show |
Applied. Sorry for the breakage. Regards, Anthony Liguori On 03/30/2012 12:54 PM, Anthony Liguori wrote: > time_t appears to be an unsigned long so use %ld. > > Reported-by: Stefan Weil<weil@mail.berlios.de> > Signed-off-by: Anthony Liguori<aliguori@us.ibm.com> > --- > qtest.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/qtest.c b/qtest.c > index 53e2b79..cd7186c 100644 > --- a/qtest.c > +++ b/qtest.c > @@ -34,7 +34,7 @@ static int irq_levels[MAX_IRQ]; > static struct timeval start_time; > static bool qtest_opened; > > -#define FMT_timeval "%" PRId64 ".%06" PRId64 > +#define FMT_timeval "%ld.%06ld" > > /** > * QTest Protocol
Am 30.03.2012 19:59, schrieb Anthony Liguori: > Applied. Sorry for the breakage. > > Regards, > > Anthony Liguori There is a new breakage: Now it will fail with w64 (which uses 64 bit time_t and a 32 bit long). Regards, Stefan W.
On 03/30/2012 01:03 PM, Stefan Weil wrote: > Am 30.03.2012 19:59, schrieb Anthony Liguori: >> Applied. Sorry for the breakage. >> >> Regards, >> >> Anthony Liguori > > There is a new breakage: > > Now it will fail with w64 (which uses 64 bit time_t and > a 32 bit long). That's a bug in w64 (it has a broken ABI). Do we actually build and run on w64?? Regards, Anthony Liguori > > Regards, > Stefan W. >
Il 30/03/2012 20:29, Anthony Liguori ha scritto: >> Now it will fail with w64 (which uses 64 bit time_t and >> a 32 bit long). > > That's a bug in w64 (it has a broken ABI). > > Do we actually build and run on w64?? It's actually sensible and x32 does the same. Not too urgent though. Paolo
On 03/30/2012 01:55 PM, Paolo Bonzini wrote: > Il 30/03/2012 20:29, Anthony Liguori ha scritto: >>> Now it will fail with w64 (which uses 64 bit time_t and >>> a 32 bit long). >> >> That's a bug in w64 (it has a broken ABI). >> >> Do we actually build and run on w64?? > > It's actually sensible and x32 does the same. Not too urgent though. I don't understand how making a long 32 bit is sensible but... I sent a patch that should at least address q64. Am not sure what x32 is though. Regards, Anthony Liguori > > Paolo
Il 30/03/2012 21:06, Anthony Liguori ha scritto: > On 03/30/2012 01:55 PM, Paolo Bonzini wrote: >> Il 30/03/2012 20:29, Anthony Liguori ha scritto: >>>> Now it will fail with w64 (which uses 64 bit time_t and >>>> a 32 bit long). >>> >>> That's a bug in w64 (it has a broken ABI). >>> >>> Do we actually build and run on w64?? >> >> It's actually sensible and x32 does the same. Not too urgent though. > > I don't understand how making a long 32 bit is sensible but... I sent a > patch that should at least address q64. > > Am not sure what x32 is though. x32 is 32-bit ABI (with 32-bit pointers and 4GB address space) with the x86-64 (64-bit) ISA. Paolo
On 03/30/2012 02:13 PM, Paolo Bonzini wrote: > Il 30/03/2012 21:06, Anthony Liguori ha scritto: >> On 03/30/2012 01:55 PM, Paolo Bonzini wrote: >>> Il 30/03/2012 20:29, Anthony Liguori ha scritto: >>>>> Now it will fail with w64 (which uses 64 bit time_t and >>>>> a 32 bit long). >>>> >>>> That's a bug in w64 (it has a broken ABI). >>>> >>>> Do we actually build and run on w64?? >>> >>> It's actually sensible and x32 does the same. Not too urgent though. >> >> I don't understand how making a long 32 bit is sensible but... I sent a >> patch that should at least address q64. >> >> Am not sure what x32 is though. > > x32 is 32-bit ABI (with 32-bit pointers and 4GB address space) with the > x86-64 (64-bit) ISA. Wow. That's.. interesting :-) In general, violating sizeof(long) >= sizeof(void *) seems like an exceeding bad idea to me. Regards, Anthony Liguori > > Paolo
Am 30.03.2012 21:16, schrieb Anthony Liguori: > On 03/30/2012 02:13 PM, Paolo Bonzini wrote: >> Il 30/03/2012 21:06, Anthony Liguori ha scritto: >>> On 03/30/2012 01:55 PM, Paolo Bonzini wrote: >>>> Il 30/03/2012 20:29, Anthony Liguori ha scritto: >>>>>> Now it will fail with w64 (which uses 64 bit time_t and >>>>>> a 32 bit long). >>>>> >>>>> That's a bug in w64 (it has a broken ABI). >>>>> >>>>> Do we actually build and run on w64?? >>>> >>>> It's actually sensible and x32 does the same. Not too urgent though. >>> >>> I don't understand how making a long 32 bit is sensible but... I >>> sent a >>> patch that should at least address q64. >>> >>> Am not sure what x32 is though. >> >> x32 is 32-bit ABI (with 32-bit pointers and 4GB address space) with the >> x86-64 (64-bit) ISA. > > Wow. That's.. interesting :-) > > In general, violating sizeof(long) >= sizeof(void *) seems like an > exceeding bad idea to me. > > Regards, > > Anthony Liguori Any 32 bit system will have to use a 64 bit time_t sooner or later to avoid an overflow. Not only w64 but also w32 supports it. Future 32 bit Linux versions will also need it. The size of a long is a different matter. Regards, Stefan W.
On 03/30/2012 02:23 PM, Stefan Weil wrote: > Am 30.03.2012 21:16, schrieb Anthony Liguori: >> On 03/30/2012 02:13 PM, Paolo Bonzini wrote: >>> Il 30/03/2012 21:06, Anthony Liguori ha scritto: >>>> On 03/30/2012 01:55 PM, Paolo Bonzini wrote: >>>>> Il 30/03/2012 20:29, Anthony Liguori ha scritto: >>>>>>> Now it will fail with w64 (which uses 64 bit time_t and >>>>>>> a 32 bit long). >>>>>> >>>>>> That's a bug in w64 (it has a broken ABI). >>>>>> >>>>>> Do we actually build and run on w64?? >>>>> >>>>> It's actually sensible and x32 does the same. Not too urgent though. >>>> >>>> I don't understand how making a long 32 bit is sensible but... I sent a >>>> patch that should at least address q64. >>>> >>>> Am not sure what x32 is though. >>> >>> x32 is 32-bit ABI (with 32-bit pointers and 4GB address space) with the >>> x86-64 (64-bit) ISA. >> >> Wow. That's.. interesting :-) >> >> In general, violating sizeof(long) >= sizeof(void *) seems like an exceeding >> bad idea to me. >> >> Regards, >> >> Anthony Liguori > > Any 32 bit system will have to use a 64 bit time_t sooner or later > to avoid an overflow. Not only w64 but also w32 supports it. > Future 32 bit Linux versions will also need it. > > The size of a long is a different matter. Yet another reason that we all should build bunkers for the upcoming Unix epoch overflow apocalypse.. that is, if the machines don't revolt before 2038 ;-) Regards, Anthony Liguori > Regards, > Stefan W. >
On Fri, Mar 30, 2012 at 19:13, Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 30/03/2012 21:06, Anthony Liguori ha scritto: >> On 03/30/2012 01:55 PM, Paolo Bonzini wrote: >>> Il 30/03/2012 20:29, Anthony Liguori ha scritto: >>>>> Now it will fail with w64 (which uses 64 bit time_t and >>>>> a 32 bit long). >>>> >>>> That's a bug in w64 (it has a broken ABI). >>>> >>>> Do we actually build and run on w64?? >>> >>> It's actually sensible and x32 does the same. Not too urgent though. >> >> I don't understand how making a long 32 bit is sensible but... I sent a >> patch that should at least address q64. >> >> Am not sure what x32 is though. > > x32 is 32-bit ABI (with 32-bit pointers and 4GB address space) with the > x86-64 (64-bit) ISA. By the way, it should be easy to add a user emulator for x32, much like sparc32plus. Some x86 target_ulongs may need to be changed to abi_ulongs and wasn't the system call interface different to the 32 bit one? > > Paolo >
On 03/30/2012 11:54 AM, Anthony Liguori wrote:
> time_t appears to be an unsigned long so use %ld.
Not portable. POSIX does not guarantee the size of time_t; there are
32-bit platforms where time_t is 64-bit.
The only way to print a time_t value is to cast it through a known-width
type, and seeing as how there are 64-bit time_t on 32-bit platforms,
that pretty much has to be %jd and intmax_t.
diff --git a/qtest.c b/qtest.c index 53e2b79..cd7186c 100644 --- a/qtest.c +++ b/qtest.c @@ -34,7 +34,7 @@ static int irq_levels[MAX_IRQ]; static struct timeval start_time; static bool qtest_opened; -#define FMT_timeval "%" PRId64 ".%06" PRId64 +#define FMT_timeval "%ld.%06ld" /** * QTest Protocol
time_t appears to be an unsigned long so use %ld. Reported-by: Stefan Weil <weil@mail.berlios.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- qtest.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)