From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IsPUE-0007TK-Fw for qemu-devel@nongnu.org; Wed, 14 Nov 2007 16:09:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IsPUC-0007Se-Ti for qemu-devel@nongnu.org; Wed, 14 Nov 2007 16:09:26 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IsPUC-0007Sb-Pr for qemu-devel@nongnu.org; Wed, 14 Nov 2007 16:09:24 -0500 Received: from bsdimp.com ([199.45.160.85] helo=harmony.bsdimp.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IsPUB-0000av-Sq for qemu-devel@nongnu.org; Wed, 14 Nov 2007 16:09:24 -0500 Date: Wed, 14 Nov 2007 14:06:58 -0700 (MST) Message-Id: <20071114.140658.41652776.imp@bsdimp.com> Subject: Re: [Qemu-devel] [PATCH] target_posix_types.h From: Warner Losh In-Reply-To: <200711142039.38427.paul@codesourcery.com> References: <473B4928.9030607@bellard.org> <1195070025.918.92.camel@phantasm.home.enterpriseandprosperity.com> <200711142039.38427.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, paul@codesourcery.com Cc: thayne@c2.net From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] target_posix_types.h Date: Wed, 14 Nov 2007 20:39:36 +0000 > > This means that time_t had to be tracked down on varying architectures > > to find the size and there was an assumption made that time_t is 32 bits > > - which isn't true for all targets. The next problem is that if the > > target is 32 bits but the host is 64 bits then there's a sign extension > > problem because (time_t)-1 is used for an error condition. If you don't > > correctly assign assign the 32-bit -1 to a 64-bit type then, rather than > > -1, you get 4294967295. > > Is there any guarantee that time_t is a signed type? The fact that you said > (time_t)-1 suggests it could be an unsigned type. If time_t is an unsigned > type, then casting to a wider value is still wrong. You have to special-case > the error condition. > > In the case of time_t this only becomes relevant after 32-bit time_t wrap in > approx. 99 years time, but I'd expect there are cases where it matters. The wrap on 32-bit signed time_t happens after ~68 years since the next looming time thing in unix is 2038: % date -r 2147483647 Mon Jan 18 20:14:07 MST 2038 % date -r 2147483648 Fri Dec 13 13:45:52 MST 1901 The standard says: 7.23 Date and time 7.23.1 Components of time [#3] The types declared are size_t (described in 7.17); clock_t and time_t which are arithmetic types capable of representing times; Which is uselessly vague (no: it doesn't imply time_t is a signed number or unsigned or even an int): 6.2.5 Types ... [#21] Integer and floating types are collectively called arithmetic types. Arithmetic types and pointer types are collectively called scalar types. Array and structure types are collectively called aggregate types. Traditionally, time_t is defined as typedef long time_t; but recently you'll see it defined like so typedef int32_t time_t; or typedef int64_t time_t; Warner