From: David G. <DGr...@am...> - 2013-11-13 22:39:23
|
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? |