From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3277 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Thu, 2 May 2013 12:13:51 +0200 Message-ID: <20130502101351.GO12689@port70.net> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> <20130501224132.GN20323@brightrain.aerifal.cx> <5181C3B4.4040801@eservices.virginia.edu> <20130502024753.GO20323@brightrain.aerifal.cx> <1367482359.28119.118.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367489650 19208 80.91.229.3 (2 May 2013 10:14:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 10:14:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3281-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 12:14:10 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXqWb-0002hl-60 for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 12:14:05 +0200 Original-Received: (qmail 7305 invoked by uid 550); 2 May 2013 10:14:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7296 invoked from network); 2 May 2013 10:14:03 -0000 Content-Disposition: inline In-Reply-To: <1367482359.28119.118.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3277 Archived-At: * Jens Gustedt [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