Making a 64-bit clean patch to the Ada runtime

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Making a 64-bit clean patch to the Ada runtime

David Gressett
I'm starting a new topic for this, as I now need to deal with the
details of producing a good patch and no longer need to discuss
the details of building the compiler package

My 5-hour build with my patch produced an Ada runtime that
completely solved all of the problems with the Ada.Calendar
component of the Ada runtime, i.e., it verified my analysis
of the problem: The part of the Ada.Calendar runtime written
in Ada, when compiled with the 32-bit MinGW compiler, sends
a 32-bit time argument to a C routine which, with the current
32-bit C compiler, expects a 64-bit time argument. The Ada
code code would, if compiled with a 64-bit compiler, produce
a 64-bit time argument which would not be a problem.

My diagnostic hack is just fine for my immediate use, but this
problem is one that should get a 64-bit clean solution that
will not break again when C and Ada components are used in a
64-bit compiler distribution. Such a solution would then be
sent upstairs to  GCC GHQ to be a part of the main

The offending bit of C code is this argument declaration:

const time_t *timer

My diagnostic hack changes that to

const int *timer

and creates a local variable declared as

time_t rt_timer;

and initializes that local variable with

rt_timer = (time_t) *timer;

rt_timer than replaces all uses of *timer in the body
of the C procedure.


What I really need here is a new C type ada_time_t
defined in such a way that sizeof(ada_time_t) will
be 32 with a 32-bit compiler and 64 with a 64-bit compiler.

I could build this with typedefs using the existing __int32
and __int64 types with something like this:

#if defined(XXXX)
typedef __int32 ada_time_t;
#else

typedef __int64 ada_time_t;
#endif /* XXXX */

What would be my best choice to replace XXXX?







------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Making a 64-bit clean patch to the Ada runtime

マーズ
Greetings David Gressett,
#include <stdalign.h>
#include <stdio.h>
#include <time.h>
#include <stdint.h>

int main() {
  alignas(uint64_t) time_t mytime;
  time_t normal;
  printf("\nsizeof %d\tsizeof %d\n", sizeof(normal),
sizeof(mytime));
  return 0;
}

gcc -Wall -std=c11 example.c

Apparently the new standard C11 have <stdalign.h> that
provides macros equivalent of C++ alignas/alignof keywords.
The above code complies and runs ok with gcc-4.8.1-3.

I think this minimalist approach to tweaking a variable's bit
alignment is better. What say you?

David Gressett wrote:

> I'm starting a new topic for this, as I now need to deal
with the
> details of producing a good patch and no longer need to
discuss
> the details of building the compiler package
>
> My 5-hour build with my patch produced an Ada runtime that
> completely solved all of the problems with the Ada.Calendar
> component of the Ada runtime, i.e., it verified my analysis
> of the problem: The part of the Ada.Calendar runtime
written
> in Ada, when compiled with the 32-bit MinGW compiler, sends
> a 32-bit time argument to a C routine which, with the
current
> 32-bit C compiler, expects a 64-bit time argument. The Ada
> code code would, if compiled with a 64-bit compiler,
produce
> a 64-bit time argument which would not be a problem.
>
> My diagnostic hack is just fine for my immediate use, but
this
> problem is one that should get a 64-bit clean solution that
> will not break again when C and Ada components are used in
a

> 64-bit compiler distribution. Such a solution would then be
> sent upstairs to  GCC GHQ to be a part of the main
>
> The offending bit of C code is this argument declaration:
>
> const time_t *timer
>
> My diagnostic hack changes that to
>
> const int *timer
>
> and creates a local variable declared as
>
> time_t rt_timer;
>
> and initializes that local variable with
>
> rt_timer = (time_t) *timer;
>
> rt_timer than replaces all uses of *timer in the body
> of the C procedure.
>
>
> What I really need here is a new C type ada_time_t
> defined in such a way that sizeof(ada_time_t) will
> be 32 with a 32-bit compiler and 64 with a 64-bit compiler.
>
> I could build this with typedefs using the existing __int32
> and __int64 types with something like this:
>
> #if defined(XXXX)
> typedef __int32 ada_time_t;
> #else
>
> typedef __int64 ada_time_t;
> #endif /* XXXX */
>
> What would be my best choice to replace XXXX?
>
>
>
>
>
>
>
>
------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 &
Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External
API Access
> Free app hosting. Or install the open source package on any
LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha
Touch and Native!
>
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> MinGW-users mailing list
> MinGW-
[hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for
the list etiquette
> may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe
at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also:
> mailto:mingw-users-
[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Making a 64-bit clean patch to the Ada runtime

Earnie Boyd
In reply to this post by David Gressett
On Wed, Nov 13, 2013 at 5:36 PM, David Gressett wrote:
>
> What I really need here is a new C type ada_time_t
> defined in such a way that sizeof(ada_time_t) will
> be 32 with a 32-bit compiler and 64 with a 64-bit compiler.
>

32bit/64bit time_t has nothing at all to do with the bitness of the
OS.  It has to do with which functions are called based on
_USE_32BIT_TIME_T with the default being 64bit time_t and 64bit
functions.

> I could build this with typedefs using the existing __int32
> and __int64 types with something like this:
>
> #if defined(XXXX)
> typedef __int32 ada_time_t;
> #else
>
> typedef __int64 ada_time_t;
> #endif /* XXXX */
>
> What would be my best choice to replace XXXX?

IDK, maybe _USE_32BIT_TIME_T?

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Making a 64-bit clean patch to the Ada runtime

David Gressett

On Friday, November 15, 2013 6:22 AM Earnie Boyd wrote:


> On Wed, Nov 13, 2013 at 5:36 PM, David Gressett wrote:
>>
>> What I really need here is a new C type ada_time_t
>> defined in such a way that sizeof(ada_time_t) will
>> be 32 with a 32-bit compiler and 64 with a 64-bit compiler.
>>

> 32bit/64bit time_t has nothing at all to do with the bitness of the
> OS. It has to do with which functions are called based on
> _USE_32BIT_TIME_T with the default being 64bit time_t and 64bit
> functions.

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.

>> I could build this with typedefs using the existing __int32
>> and __int64 types with something like this:
>>
>> #if defined(XXXX)
>> typedef __int32 ada_time_t;
>> #else
>>
>> typedef __int64 ada_time_t;
>> #endif /* XXXX */
>>
>> What would be my best choice to replace XXXX?

> IDK, maybe _USE_32BIT_TIME_T?

What I really need is a way for the C compiler to tell me its
bitness; I am assuming that the Ada compiler will always have the
same bitness. I'm guessing  from things in the mailing list
and the MinGW web site that a 64-bit compiler suite is in
development. I have no knowledge at this point how the C runtime
and C include files for any new MinGW 64-bit C will be constructed.

A simple solution would be for the types.h file to contain
something roughly equivalent to the Ada Standard'Address_Size -
perhaps something like

typedef __int32 __standard_address_size;

for the current 32-bit compiler and

typedef __int64 __standard_address_size;

for a new 64-bit compiler.

The definition of ada_time_t in the Ada runtime patch
would then be the very simple

typedef __standard_address_size ada_time_t;

This would break compilation of the Ada runtime for other compiler
projects such as MinGW-w64 and TDM-GCC, but that problem could
be easily solved with a bit of communication with the people who
run those projects. The patch could then go to the upstream GCC
general headquartes. It won't affect any other platforms, but it
would serve as an example to the developers of other 32-bit
platforms - there is no fundamental reason why developers of other
32-bit platforms could not create a 64-bit time_t type, which would
then break the Ada runtime build on those platforms, just as it did
for MinGW32.

(If if there is something like __standard_address_size already in
place, that could be used. I didn't see anything obvious when looking
through types.h, but I didn't look anywhere else.)

The upstream GCC project probably won't get any such patch in place
until their next release, which could be GCC 4.8.3 or 4.9.0. Until
that happens, a local MinGW patch would have to fix the problem.
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Making a 64-bit clean patch to the Ada runtime

Earnie Boyd
On Fri, Nov 15, 2013 at 12:44 PM, David Gressett  wrote:

>
> On Friday, November 15, 2013 6:22 AM Earnie Boyd wrote:
>
>
>> On Wed, Nov 13, 2013 at 5:36 PM, David Gressett wrote:
>>>
>>> What I really need here is a new C type ada_time_t
>>> defined in such a way that sizeof(ada_time_t) will
>>> be 32 with a 32-bit compiler and 64 with a 64-bit compiler.
>>>
>
>> 32bit/64bit time_t has nothing at all to do with the bitness of the
>> OS. It has to do with which functions are called based on
>> _USE_32BIT_TIME_T with the default being 64bit time_t and 64bit
>> functions.
>
> 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.
>

No, it doesn't have to do with the bitness of the compiler either.
The 32bit time_t functions as well as the 64bit time_t functions exist
in both versions of the compiler because they are in the runtime.

>>> I could build this with typedefs using the existing __int32
>>> and __int64 types with something like this:
>>>
>>> #if defined(XXXX)
>>> typedef __int32 ada_time_t;
>>> #else
>>>
>>> typedef __int64 ada_time_t;
>>> #endif /* XXXX */
>>>
>>> What would be my best choice to replace XXXX?
>
>> IDK, maybe _USE_32BIT_TIME_T?
>
> What I really need is a way for the C compiler to tell me its
> bitness; I am assuming that the Ada compiler will always have the
> same bitness. I'm guessing  from things in the mailing list
> and the MinGW web site that a 64-bit compiler suite is in
> development. I have no knowledge at this point how the C runtime
> and C include files for any new MinGW 64-bit C will be constructed.
>

What you really need to do is create 64bit time_t and 32bit time_t in
the ada runtime and then define time_t and the base functions based on
_USE_32BIT_TIME_T.  It is how the C runtime works.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Making a 64-bit clean patch to the Ada runtime

George Koehler
In reply to this post by David Gressett
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.)

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.

--George Koehler

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Making a 64-bit clean patch to the Ada runtime

マーズ
Hello everybody! Good to see a lot of interest in 32/64 bit
compatability.

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.)
>
> 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.
>
> --George Koehler
>
>
------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 &
Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External
API Access
> Free app hosting. Or install the open source package on any
LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha
Touch and Native!
>
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> MinGW-users mailing list
> MinGW-
[hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for
the list etiquette
> may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe
at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also:
> mailto:mingw-users-
[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Making a 64-bit clean patch to the Ada runtime

David Gressett
In reply to this post by George Koehler

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.



------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe