Re: sign (in)consistency between architectures

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

Am Donnerstag, den 02.05.2013, 12:13 +0200 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@inria.fr> [2013-05-02 10:12:39 +0200]:
> > I would prefer to have both worlds by using uint64_t (or directly the
> > underlying base type) uniformly. There is no reason to have it signed:
> > 
> 
> yes probably that's the best solution
> 
> but note that even that can hurt: i've seen code like
> 
>   t = (double)clock();
> 
> (eg the time module in python does this) where interesting
> low bits may get lost if clock_t is uint64_t


*and* if the actual value is larger than (1ull << 50) or something
like that.

An application that is interested in the low bits (probably most of
them are) should probably compute the integer and fractional parts of
the time in seconds by using CLOCKS_PER_SECOND, anyhow.

> this might be common because clock_t is permitted to be
> a floating-point type

yes, any real type is permitted in C, I think.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]