From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IsPlk-0004YH-Hv for qemu-devel@nongnu.org; Wed, 14 Nov 2007 16:27:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IsPli-0004UL-Je for qemu-devel@nongnu.org; Wed, 14 Nov 2007 16:27:31 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IsPli-0004Td-1R for qemu-devel@nongnu.org; Wed, 14 Nov 2007 16:27:30 -0500 Received: from owa.c2.net ([207.235.78.2] helo=email.c2.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IsPlh-0000tw-O1 for qemu-devel@nongnu.org; Wed, 14 Nov 2007 16:27:29 -0500 Subject: Re: [Qemu-devel] [PATCH] target_posix_types.h From: Thayne Harbaugh In-Reply-To: <200711142039.38427.paul@codesourcery.com> References: <1195055987.918.34.camel@phantasm.home.enterpriseandprosperity.com> <473B4928.9030607@bellard.org> <1195070025.918.92.camel@phantasm.home.enterpriseandprosperity.com> <200711142039.38427.paul@codesourcery.com> Content-Type: text/plain Date: Wed, 14 Nov 2007 14:19:27 -0700 Message-Id: <1195075167.918.103.camel@phantasm.home.enterpriseandprosperity.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: thayne@c2.net, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Wed, 2007-11-14 at 20:39 +0000, Paul Brook wrote: > > 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. time_t is only one example. There are similar problems with the handling of struct target_iovec. There are still other places with similar problems. Yes, special casing can work. There's the possible problem of value truncation when moving between 32 and 64 bits.