From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: PRI_stime Date: Tue, 20 Oct 2015 10:22:08 +0200 Message-ID: <5625F9B0.4030403@suse.com> References: <5625FAC802000078000AC955@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZoSBP-0006Nb-Ja for xen-devel@lists.xenproject.org; Tue, 20 Oct 2015 08:22:11 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Jan Beulich Cc: xen-devel , Dario Faggioli List-Id: xen-devel@lists.xenproject.org On 10/20/2015 10:10 AM, George Dunlap wrote: > On Tue, Oct 20, 2015 at 7:26 AM, Jan Beulich wrote: >> George, Dario, >> >> it being mostly used in scheduler code, and me considering it quite a >> bit easier to compare such big numbers when shown in hex I wonder: >> Do you prefer this to stay PRId64, or would you accept it to be >> changed to PRIx64 (allowing it to be used in a few other places)? > > Personally I've never taken the time to familiarize myself with the > magnitude of hex numbers vs decimal numbers; so in the case of time, I > could easily see that 10000000 nanoseconds is about 1ms; but I don't A good example for doing it in hex. Less digits are less error prone. Your example would translate to 10ms. :-) > have a good sense of how long 0x1000000 nanoseconds is. The fact that 0x100000 is about 1 million. This helps a lot to get an idea of the magnitude. > our times are based on base 10 instead of base 2 is I think as good an > argument as any for leaving it as a decimal. > > But I wouldn't oppose the change if Dario (or others) thought x64 was > the way to go. +1 for hex. Juergen