Building on Windows from scratch - difftime problem found ( was datediff )

[Gary Bilkus]

On 25/01/2014 15:37, John Ralls wrote:
> On Jan 25, 2014, at 5:49 AM, Gary Bilkus <mail at gary.bilkus.com> wrote:
>
>> On 24/01/2014 17:08, Derek Atkins wrote:
>>> John Ralls <jralls at ceridwen.us> writes:
>>>
>>>> if (sizeof(time_t) == 8)
>>>>    return (double)((int64)time1 - (int64)time2);
>>>> else
>>>>    return (double)((int32)time1 - (int32)time2);
>>> This code probably wouldn't compile cleanly.  It would complain about
>>> casting to different sizes.  Even though theoretically the compiler
>>> should be able to optimize the branch by noticing that it is always true
>>> or always false, it will still complain about the unused branch.  (I
>>> know this from personal experience).
>>>
>>>> That could be done as a macro and inserted into one of the header
>>>> files in each library.
>>>>
>>>> Regards,
>>>> John Ralls
>>> -derek
>>>
>> Given that time_t is always a signed integer value, wouldn't
>>
>> return (double)(time1-time2)
>>
>> just work anyway, at least as far as a patch for mingw is concerned?
> Only if the binary never leaves the machine on which it was compiled. The problem arises when the program compiled with one size of time_t is run with an msvcrt with the other size. Keith Mashall explains it pretty clearly in the second and third emails in that thread I cited a couple of days ago.
>
> Regards,
> John Ralls
>
Hold on though.  These solutions don't call MSVCRT at all, so why does 
that matter?  And if it did, why would your solution work anyway, given 
that sizeof is evaluated at compile time? (leaving aside Derek's point 
that it might not compile cleanly.

It seens that trying to find a way of guaranteeing to call the right 
version of MSVCRT correctly is way harder than just getting the correct 
result!