Size of time_t in gnutls4win

[Simon Josefsson]

Tim Kosse <tim.kosse at filezilla-project.org> writes:

> The Windows GnuTLS binaries from http://josefsson.org/gnutls4win/ seem
> to be compiled in an environment with a 32bit time_t at least in 2.6.4
> and 2.8.1, the versions I have tried.

Yes, both were built using the same mingw32 Debian package.

> I'm using Visual Studio 2008 and on that platform time_t is 64bit in
> size.

And ming32 appears to use a 32 bit time_t:

jas at mocca:~$ cat foo.c
#include <time.h>
#include <stdio.h>

int main() {
  printf ("time_t %d\n", sizeof (time_t));
  return 0;
}
jas at mocca:~$ i586-mingw32msvc-gcc -o foo.exe foo.c
jas at mocca:~$ ./foo.exe
time_t 4
jas at mocca:~$ 

> The GnuTLS functions that have a time_t either as argument or as return
> type thus have undefined behavior.
>
> For example gnutls_x509_crt_get_expiration_time from the DLL returns a
> 32bit number, whereas the calling program expects a 64bit number. The
> result is that the leading 32 bits of the value after the call are
> whatever else was on the stack at the time of the call.
>
> The behavior of functions expecting a time_t as argument will probably
> be even more problematic.

Yes, this sounds bad.

> I think instead of time_t a type should be used that's been chosen at
> compile time of GnUTLS to match the size of time_t of the build environment.

Yes, one needs to be sure to use the same ABI when linking different
components.

Some options:

1) Configure Visual Studio 2008 to use a 32-bit time_t.

  Does defining _USE_32BIT_TIME_T works?  It seems this is required for
  Visual Studio 2005/2008 to get a 32-bit time_t.  Reference:

  http://www.mail-archive.com/libtool-patches@gnu.org/msg04555.html

  This should solve your problem directly.

2) Change GnuTLS binary packages to use a 64-bit time_t.

  This will break with older Visual Studio.  I'm not sure it is a good
  idea.

3) Provide GnuTLS packages for both 32-bit and 64-bit time_t.

  This would seems to double the time to build Windows binaries, and
  building Windows binaries already is a pain for me.

4) Provide two ABIs for these functions under Windows, and use header
   file #if's to map the API to the right ABI.

  This may be the best solution long term, but requires that someone
  implements this.

/Simon