On Wed, 03 Jun 2015 08:40:37 +0100, Pekka Paalanen <[email protected]> wrote:
On Tue, 02 Jun 2015 17:03:30 +0100
"Ben Avison" <[email protected]> wrote:
If I were to make one change to gettimei() now, looking back, it would be
to make it return int32_t instead. This is because most often you'd be
subtracting two sample outputs of the function, and it's more often
useful to consider time intervals as signed (say if you're comparing the
current time against a timeout time which may be in the past or the
future). If gettimei() returns a signed integer, then C's type promotion
rules make the result of the subtraction signed automatically.
Wasn't overflow well-defined only for unsigned integers?
You're right, I'd forgotten that aspect of C. To be fully portable, a
modulo-2^32-arithmetic comparison needs to be written
uint32_t time1, time2;
if (((time1 - time2) & (1u<<31)) != 0)
rather than
int32_t time1, time2;
if ((time1 - time2) < 0)
or
uint32_t time1, time2;
if ((int32_t) (time1 - time2) < 0)
even though the latter two are more readable and all three are actually
equivalent if you're using two's complement integers, which (nearly?)
everybody does nowadays.
Sometimes I wish C had an inbuilt modulo integer type. At the assembly
level for a lot of CPUs it's a third type of comparison with similar ease
of use as signed and unsigned comparisons, but it's a pain to express in
C.
Anyway, this doesn't change the fact that struct timeval currently uses
signed long ints, and will enter undefined behaviour territory in 2038. I
think it's reasonable to assume that in practice, tv_sec will actually
contain an unsigned long int value (albeit one that has been cast to
signed) after that, as that would break the least software.
Ben
_______________________________________________
Pixman mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pixman
