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, ... _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
