On 25/01/2014 15:37, John Ralls wrote:
On Jan 25, 2014, at 5:49 AM, Gary Bilkus <m...@gary.bilkus.com> wrote:
On 24/01/2014 17:08, Derek Atkins wrote:
John Ralls <jra...@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!
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
