On 27/01/2014 17:20, John Ralls wrote:
On Jan 27, 2014, at 8:29 AM, Derek Atkins <warl...@mit.edu> wrote:
Gary Bilkus <m...@gary.bilkus.com> writes:
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?
Is it always a signed integer? Can't it sometimes be unsigned?
This is the "year 2037" problem, where 32-bit unsigned time rolls over.
However there is also a "Year 2106" problem, which is where 32-bit
unsigned time rolls over. I think there *are* some systems where it's
unsigned, but still 32 bits. Or at least there are apps where that is
the case.
It's actually the "2038 problem", as a signed 32-bit time_t overflows at
03:14:07 2038-01-19.
Representation of time_t is up to the C library unless the application
re-implements all of the standard C functions which use it including retrieving
the tick count from the system clock.
http://en.wikipedia.org/wiki/Unix_time#Representing_the_number reports that QNX
V6 implements it as unsigned, but that it's generally implemented as signed. I
don't think there's any reason to port GC to QNX.
None of which matters a whole lot. We needed dates past 2038 to support
scheduled transactions, so we don't use time_t. AQBanking and LibOFX aren't
AFAICT concerned about far-future dates, so for the moment time_t, even 32 bit,
is fine.
The real problem we're dealing with here is that MinGW screwed up handling
Microsoft's time_t size arrangements, effectively breaking it for 64-bit
values. Until they sort that out, ISTM the solution is to coerce 32-bit time_t
on 64-bit builds.
Regards,
John Ralls
The answer to the 'is it always a signed integer' question is: yes, on
mingw it is, and since we're discussing a patch for the windows port,
does it matter if there are any really weird unix variants which use
unsigned ( and I do mean weird ). The problem with the simple code I
proposed above is the edge case caused if time1 is very large and
positive, and time2 is very large and negative, meaning the result would
overflow even a 64 bit int before being coerced to double. But that
isn't going to happen with any plausible use case for these libraries (
the only time ofx uses the function is in a minor correction of a few
hours to the date based on some timezone subtleties as far as I can tell ).
If I were writing a library for use by the entire world, I'd care that
time_t might be unsigned on some variant. Since I'm just trying to find
a patch which allows gnucash to compile on Windows, and should never be
applied elsewhere, I don't care if time_t is sometimes unsigned on unix
boxes.
But I don't own the project, so I'm still looking for a definitive
understanding of what is likely to be acceptable as a patch which
eventually gets into the official repository. It's not urgent for me,
because I have what I need now, which is a way of compiling gnucash on
windows which works, and I can therefore start to investigate the stuff
I wanted to do in the first place!
But I'm still happy to help if I get a clear steer.
And of course if I hit any further issues, I'll be happy to
investigate/report
BTW, even on a 64bit machine, the mingw tools as used in geert's scripts
produce 32bit executables. However, the only way to produce an
executable which will work on all the supported windows OSs seems to be
to compile on an XP box as otherwise it fails on XP with various
complaints about missing libraries.
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
