From: Andreas Schwab <hidden> Date: 2016-07-12 13:31:22
Johannes Schindelin [off-list ref] writes:
Hi Andreas,
On Tue, 12 Jul 2016, Andreas Schwab wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
quoted
PRIuMAX isn't compatible with time_t.
That statement is wrong.
No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t
(even if they happen to have the same representation).
Sigh.
So if it is wrong, what is right?
The right thing is to add a cast, of course.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
From: Jeff King <hidden> Date: 2016-07-12 13:47:02
On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Hi Andreas,
On Tue, 12 Jul 2016, Andreas Schwab wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
quoted
PRIuMAX isn't compatible with time_t.
That statement is wrong.
No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t
(even if they happen to have the same representation).
Sigh.
So if it is wrong, what is right?
The right thing is to add a cast, of course.
In general, I think the right cast for time_t should be to (intmax_t),
and the formatting string should be PRIdMAX (which, as an aside, needs
an entry in git-compat-util.h).
In this particular code (show_date_relative), though, I think you can
get away with treating it as unsigned, because it's not actually a
time_t but rather a difference. And we handle the negative difference at
the top of the function already ("in the future").
-Peff
On Tue, Jul 12, 2016 at 3:46 PM, Jeff King [off-list ref] wrote:
On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
Hi Andreas,
On Tue, 12 Jul 2016, Andreas Schwab wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
quoted
PRIuMAX isn't compatible with time_t.
That statement is wrong.
No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t
(even if they happen to have the same representation).
Sigh.
So if it is wrong, what is right?
The right thing is to add a cast, of course.
In general, I think the right cast for time_t should be to (intmax_t),
and the formatting string should be PRIdMAX (which, as an aside, needs
an entry in git-compat-util.h).
Coincidentally, I have the same problem with unsigned long being
32-bit and have to switch to off_t in some places. Does anybody know
what a fallback in git-compat-util for PRIdMAX would look like? I
guess it's "lld"...
--
Duy
From: Johannes Schindelin <hidden> Date: 2016-07-13 11:31:52
Hi Duy,
On Tue, 12 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 12, 2016 at 3:46 PM, Jeff King [off-list ref] wrote:
quoted
On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Tue, 12 Jul 2016, Andreas Schwab wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
quoted
PRIuMAX isn't compatible with time_t.
That statement is wrong.
No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t
(even if they happen to have the same representation).
Sigh.
So if it is wrong, what is right?
The right thing is to add a cast, of course.
In general, I think the right cast for time_t should be to (intmax_t),
and the formatting string should be PRIdMAX (which, as an aside, needs
an entry in git-compat-util.h).
Coincidentally, I have the same problem with unsigned long being
32-bit and have to switch to off_t in some places. Does anybody know
what a fallback in git-compat-util for PRIdMAX would look like? I
guess it's "lld"...
Yes, judging from the existing fallback for PRIuMAX, "lld" would be the
correct thing to do. And then it would be nice to introduce
#define PRIdMAX "I64d"
next to the PRIuMAX definition in compat/mingw.h, too.
Ciao,
Dscho