Date: Thu, 17 Jan 2013 01:28:54 +0100 From: Polytropon <freebsd@edvax.de> To: "Thomas D. Dean" <tomdean@speakeasy.org> Cc: questions@freebsd.org Subject: Re: time_t definition Message-ID: <20130117012854.1170d49c.freebsd@edvax.de> In-Reply-To: <50F71C5E.9040207@speakeasy.org> References: <201301161841.r0GIfgWS054810@mail.r-bonomi.com> <50F71C5E.9040207@speakeasy.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Jan 2013 13:32:14 -0800, Thomas D. Dean wrote: > On 01/16/13 10:41, Robert Bonomi wrote: > > > *precisely* and the format string had "%ld". > > this IS a type mismatch, if a 'long' is a 64-bit value. > > The original code was compiled on a 32-bit machine for a 32-bit target. > I tried %d, %ld, and %lld with the same result. That's normal. As I did show in my previous message, (time_t) boils down to (int) which is as wide as the CPU architecture "naturally" uses it: On a 32 bit CPU, (int) is 32 bit, and on a 64 bit CPU, it's 64 bit. That's why you'll probably see something interesting when you use the source Luke for how the UFS file system stores time values: It uses (ufs_time_t) which is a typedef for (int64_t), a type that explicitely requires 64 bit, no matter if you're on a 32 bit CPU or a 64 bit CPU. Imagine it would be otherwise... ;-) > > FALSE. Calculation is OK. I/O format conversion is problematic. > > In the simple example I posted, gcc did not complain of a format mismatch. Because there was no format mismatch. > But, in the case of time_t gcc does complain of a format mismatch. As explained, this is _normal_. :-) > Both cases had the same number of typedef levels to get to a basic type > and used the same compile command. Should have the same result... It's not about the number of typedefs; it's about what it boils down to if you follow the chain to the machine level. :-) > I am attempting to understand the difference. Probably you will from my previous message. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130117012854.1170d49c.freebsd>