On 17/01/10 13:51, Roumen Petrov wrote:
> Tor Lillqvist wrote:
>>> No 64bit time it is MS CRT>= 8.0 and don't impact earlier versions.
>> Sigh. Let me draw an example. Say you have a library foo, which in its
>> header<foo.h> has:
>> void foo_do_something (time_t when);
>> Now, the libfoo binary has been built with a traditional mingw where
>> time_t is 32 bits. Now somebody uses a hypothetical (?) newer mingw
>> that with some option (or by default) makes time_t mean a 64 bit type,
>> and compiles code that calls the foo_do_something() function. You see
>> the problem? No compilation warnings or errors, it will just work
>> mysteriously wrong.
> If you like to know more about please visit
> - http://msdn.microsoft.com/en-us/library/w4ddyt9h(VS.80).aspx
> - http://msdn.microsoft.com/en-us/library/kdfaxaay(VS.80).aspx
> I won't discuss Microsoft design.
My best guess is that MS didn't switch from an 32bit to a 64bit time_t
value, to avoid the resulting ABI break. Instead they implemented the
64bit support as an optional feature in the runtime, but left the 32bit
as the default. Old applications keep working and new code can start
using the 64bit support if they want to. Makes perfectly sense for an OS
that needs to maintain backwards compatibility with existing apps. On a
typical linux systems this switch is less problematic since a
distribution can recompile all apps with a 64bit time_t.
Note that msvc has 64bit time_t support for a very long time (at least
all the way back to Win95 if I'm correct). It was just not enabled by
default until their version 2005 compiler.
But this has nothing to do when *you* are writing a libfoo library. If
you want your library to be binary compatible with different
runtimes/compilers, you certainly don't want to depend on something that
you do not have control over yourself, such as the time_t type. So for
maximum portability you define your own time_t type as a 64bit value:
typedef int64_t libfoo_time_t;
void foo_do_something (libfoo_time_t when);
And in the implementation, you can use 32bit or 64bit depending on what
your compiler or runtime supports.
void foo_do_something (libfoo_time_t when)
Of course your implemention will suffer from the year 2038 problem if
you do use 32bit time_t internally. But you won't run into binary
incompatibility. And as a bonus, you can easily upgrade your 32bit
implementation to a 64bit one without introducing an ABI break.
For instance if I would implement this for my library and compile with
current mingw (32bit), it would work perfectly fine from a msvc compiled
app (regardless of whether it has a 32 or 64bit time_t). Once the 64bit
time_t becomes available for mingw too, I can adapt my implementation to
use it internally and from the outside it will appear that nothing has
changed. Except that my year 2038 bugs are now gone of course.