time_t definition

[Polytropon]

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, ...