From: Alan W. I. <ir...@be...> - 2009-02-16 19:33:51
|
On 2009-02-14 16:05-0000 trc wrote: > Hi Alan, > > Alan W. Irwin wrote: >> >>> [out of order] 4. qsastime_testlib cannot be built with MSVC 2008 as >>> setenv and unsetenv >>> are not implemented. >>> >>> [so] the above changes >>> are untested. >> >> Is this a showstopper for MSVC 2008 or do you think you can find for that >> platform (a) some library alternatives for setenv and unsetenv, (b) some >> other alternative to set the time zone to zero temporarily which would make >> mktime act like an inverse to gmtime, or (c) some other alternative that is >> equivalent to the Linux timegm or the inverse of gmtime? >> > > > There are too many problems to make qsastime_testlib worthwhile on 32 bit Windows XP with MSVC 2008 (and earlier editions) even with 64 bit time_t values. > 32 bit Windows XP / MSVC 2008 has extensions for 64 bit time_t values and a function _mkgmtime64 for converting times a struct tm to 64 bit time_t. Unfortunately mkgmtime64 returns -1 for all times prior to 1/1/1970. > A further problem for qsastime_testlib is that the MSVC debug version of strftime throws an exception for years less than 0 or greater than 9999. > For the record MSVC has the (unix) putenv function which can be used to implement setenv and unsetenv. However googling putenv suggests there could be problems with memory leaks and care has to be taken over ownership/lifetime of the environment variables. Further it is unclear how an environment variable is set to empty string. eg. > setenv("TZ","",1) -> putenv("TZ=") > This unsets TZ rather than setting it to an empty string. > > Default 32 bit Cygwin compiles and links but has 32 bit time_t so testing is not done. I didn't investigate if there were 64bit time_t extensions. > Note my investigations were on a 32bit Windows XP system so this excludes 32 bit Vista and 64bit versions of XP and Vista. Hi Terrence: Thanks very much for these further investigations. It sounds like _mkgmtime64 is the exact equivalent to the required timegm. Too bad it doesn't work for your particular Windows version, but that function is probably the first thing that should be investigated on other Windows platform to see if the limitation on negative time_t values has been removed. It's possible it is not working for you because you have a 32-bit system. Certainly, Linux versions of timegm and gmtime are incredibly limited on 32-bit hardware (time_t limited to just 32-bits). I am not surprised that Cygwin has the same issue on 32-bit hardware. Further investigation of putenv might be worthwhile. My guess is that unsetting TZ is quite likely to make mktime act just like mkgmtime, but the question is whether there are limitations in the 64-bit version of mktime. Again, that may depend on whether the Windows hardware platform is 32-bit or 64-bit. Of course, the purpose of qsastime_testlib is to test libqsastime for extreme time ranges, but because of those extreme ranges you tend to run into limitations of the testing platform's libraries as you have found out on your 32-bit Windows platform, and as any 32-bit Linux user will also find out. Fortunately, I have found at least one platform (Linux 64-bit) where qsastime_testlib works. That is a most important result which gives me great general confidence in libqsastime. For other platforms, testing over a limited time range with qsastime_test, and taking account of the good Linux 64-bit results for qsastime_testlib is probably sufficient to give confidence in libqsastime for those platforms as well. However, it would be nice if someone also finds a Mac OS X platform and Windows platform where qsastime_testlib works as well just to make sure there are no platform-dependent limitations built into libqsastime (note that is a different and much more important issue than limitations in the test code) for extreme time ranges. My guess is both qsastime_test and qsastime_testlib will work fine on 64-bit Mac OS X platforms. But I would like to see that confirmed. qsastime_test should work on OS X 32-bit platforms. qsastime_testlib might even work on OS X 32-bit platforms if they have 64-bit time_t available. Obviously, there are problems building and running qsastime_testlib on the limited (32-bit XP) Windows platforms that have been tested so far. If 64-bit and/or Vista Windows also have problems, then we can limit what is tested in qsastime_testlib to make it work on Windows. For example, it would be easy enough to change the test code so the call to strftime was skipped for Windows. Also, I have discussed off-list with Werner the possibility of dropping one of the tests for windows so that my_timegm is never called in that case. We could also drop the gmtime call if that is also problematic on windows for a wide range of times. That still leaves us with the extremely worthwhile and essential test of whether setFromUT and breakDownMJD are inverses of each other for an extreme range of times on Windows. However, I still have some hope that there are some Windows platforms where the limitations on time functions for 32-bit XP that you reported above have been removed so this dumbing down of the tests will not be necessary for the windows case. The current (revision 9531) status of libqsastime is all tests pass with flying colours on 64-bit Linux, and I have no further changes planned for setFromUT, breakDownMJD, or strfMJD or the comprehensive tests (which now take 10 minutes of cpu time to do 100 million different calls of testlib_broken_down_time and 74 million different calls of testlib_MJD) of those functions. I have heard privately from Tony Allen that he may have a few more changes in mind for those functions. That's fine since we have a strong testing environment to make sure further changes do not introduce errors, and this is a golden opportunity to get everything right for this library before we start being restricted by backwards compatibility concerns. I now plan to start working on the wrapper functions mentioned in README.qsastime_API. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |