[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130502101351.GO12689@port70.net>
Date: Thu, 2 May 2013 12:13:51 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: sign (in)consistency between architectures
* Jens Gustedt <jens.gustedt@...ia.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
this might be common because clock_t is permitted to be
a floating-point type
of course this should not be a problem if the cast is
applied to the difference only
(other than uint64->double conversion is usually much
slower than int32->double conversion)
..but this issue is present on 64bit platforms anyway
siginfo is affected as well: clock_t is used in the union
in it which i think is aligned with glibc now
but i'm not against the uint64_t solution if we decide
breaking glibc abi here is ok
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
