[Pixman] RFC: Pixman benchmark CPU time measurement

Ben Avison bavison at riscosopen.org
Wed Jun 3 09:45:18 PDT 2015

On Wed, 03 Jun 2015 08:40:37 +0100, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 02 Jun 2015 17:03:30 +0100
> "Ben Avison" <bavison at riscosopen.org> 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)


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

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.


More information about the Pixman mailing list