Re: [Mingw-users] Making a 64-bit clean patch to the Ada runtime

[David G. <DGr...@am...>]

on Friday, November 15, 2013, George Koehler wrote:

> On 11/15/13 12:44, David Gressett wrote:
>> I know that 32bit/64bit time_t has nothing at all to do with the 
>> bitness of the OS, the problem is the bitness of the compilers, which 
>> can be different from that of the OS. I run the MinGW compilers on 
>> three different computers, one 32-bit XP, the other two are 64-bit 
>> Windows 7.

> We are confusing two things.

> It is wrong to assume that addresses and time_t have the same size. For 
> example, my OpenBSD/amd64 uses 64-bit pointers and 32-bit time_t. (I 
> need to upgrade it before 2038.)

The source of the problem that I am trying to solve is that the developers
of the Ada runtime library have made exactly that assumption.

> MinGW goes the other way: it uses 32-bit pointers and 64-bit time_t. For 
> compatibility, mscvrt.dll can do either 32-bit or 64-bit time_t, but 
> MinGW runtime picks 64-bit time_t by default. This is a good idea, 
> because it prevents the year 2038 bug.

> It is normal to have integers of different sizes. Even though MinGW is a 
> 32-bit compiler, I can still write C code with 'long long' or 'int64_t' 
> or '__int64' or 'INT64' or any 64-bit data type. As time_t is just 
> another data type, time_t can be 64-bit if the libraries want.

> ----

> David Gressett would like to define ada_time_t, which might look like

> #include <stdint.h>
> typedef intptr_t ada_time_t;

> or perhaps

> #include <windows.h>
> typedef LONG_PTR ada_time_t;

> Because intptr_t or LONG_PTR is already the same size as an address, 
> ada_time_t would also be the same size as an address.

> Earnie Boyd's idea to check _USE_32BIT_TIME_T would not work, if 
> ada_time_t needs to be the same size as an address, not a time_t.

> I am not sure if David Gressett's ada_time_t is the best idea. It would 
> restrict ada_time_t to 32 bits even when time_t is 64 bits. It might be 
> better to define ada_time_t as 64-bit (in both Ada code and C code) and 
> put (time_t) casts in the C code. Or it might be better to teach the Ada 
> code when time_t is 64-bit.

I'm not trying to restrict ada_time_t to 32 bits; I'm trying to get an
ada_time_t that follows the Ada-defined time_t type used in the Ada
source code. That type will be a 32-bit type when  compiled with a 32-bit
Ada compiler, but will be a 64-bit type when compiled with a 64-bit Ada 
compiler.

The Ada developers, in addition to the assumption that the C time_t type
is always the sime size as an address type, have apparently also decided
that the part of the Ada run time library that is written in Ada will be
the same for all platforms and that the system dependencies will all be 
handled in the small part of the Ada runtime library that is written in C.
That is not an unreasonable philosophy - the conditional compilation 
capability of C that can be so easily controlled by the #ifdef directive
has no Ada equivalent. 

a 64-bit clean fix is also made a bit more difficult by the design of
the makefiles in the Ada part of the compiler build system. The CFLAGS
mechanism is used by the makefiles to feed parameters to the C compiler 
that can be used to deal with problems like this. Unfortunately, it seems
that the Ada developers have closed off this mechanism for controlling
the C part of the build of the Ada runtime library - examination of
my build log shows that the _USE_32BIT_TIME_T does not appear in the
CFLAGS used in the makefile that controls the runtime build, even though
it does show up in other places. There was at one time an ADA_CFLAGS that 
was visible there, but the changelogs show that it was removed.

intptr_t looks good - it doesn't require the addition of anything new 
to the C runtime, so it will be used in my next build.