* A problem with the Ada.Calendar runtime package as implemented by the MinGW project
@ 2013-11-15 23:20 David Gressett
2013-11-16 0:16 ` David Gressett
0 siblings, 1 reply; 2+ messages in thread
From: David Gressett @ 2013-11-15 23:20 UTC (permalink / raw)
To: gcc-help
I have identified a problem with the GCC Ada runtime Ada.Calendar
package as implemented by the MinGW project in its binary
distribution, which is a 32-bit compiler suite for the Microsoft
Windows platform. I have identified a solution to the problem, but
I need some information so that I can build a patch for the problem
that will be suitable for submission to the GCC developers.
The problem is that the time functions in the Ada.Calendar package,
such as Clock and Time_Of return incorrect results. The problem
starts with a procedure call in the Ada source code of the Ada.Calendar
package.
This is the definition of that procedure in Ada source code:
type time_t is
range -(2 ** (Standard'Address_Size - Integer'(1))) ..
+(2 ** (Standard'Address_Size - Integer'(1)) - 1);
type time_t_Pointer is access all time_t;
procedure localtime_tzoff
(timer : time_t_Pointer;
is_historic : int_Pointer;
off : long_Pointer);
pragma Import (C, localtime_tzoff, "__gnat_localtime_tzoff");
__gnat_localtime_tzoff is implemented in a C file named sysdep.c
and starts like this:
void
__gnat_localtime_tzoff (const time_t *timer, const int *is_historic, long *off)
There is an implicit assumption here that the time_t type
defined in the Ada source code and the C time_t are the same size.
The latest version of the MinGW C runtime breaks that assumption -
it has both 32- and 64-bit time_t types; the 64-bit time_t
is the default, but the 32-bit version can be selected by using a
#define _USE_32BIT_TIME_T directive.
The result of the default is that the Ada procedure call feeds a
32-bit value to the C routine which expects a 64-bit value, with
predictably disastrous consequences.
There ate two possible quick-and-dirty patches that would fix the
problem for the MinGW binary distribution.
1. use #define _USE_32BIT_TIME_T
2. change "const time t *timer" to "const int *timer", with the
appropriate patches in the body of the procedure to convert the
int value to a time_t value where needed.
Neither of these are appropriate for a patch to be submitted
to the GCC maintainers - they are not 64-bit clean.
I need a bit of information about the philosophy governing
patches to the GCC Ada runtime source code. It appears to me
that the idea is to confine system-dependent code and patches to
the C side in sysdep.c and leave the Ada source code identical
for all platforms, so that a proposed patch that modifies the Ada
code would be rejected.
A confirmation of this philosophy will be useful to me when
discussing this issue with the MinGW developers.
^ permalink raw reply [flat|nested] 2+ messages in thread
* A problem with the Ada.Calendar runtime package as implemented by the MinGW project
2013-11-15 23:20 A problem with the Ada.Calendar runtime package as implemented by the MinGW project David Gressett
@ 2013-11-16 0:16 ` David Gressett
0 siblings, 0 replies; 2+ messages in thread
From: David Gressett @ 2013-11-16 0:16 UTC (permalink / raw)
To: gcc-help
I have identified a problem with the GCC Ada runtime Ada.Calendar
package as implemented by the MinGW project in its binary
distribution, which is a 32-bit compiler suite for the Microsoft
Windows platform. I have identified a solution to the problem, but
I need some information so that I can build a patch for the problem
that will be suitable for submission to the GCC developers.
The problem is that the time functions in the Ada.Calendar package,
such as Clock and Time_Of return incorrect results. The problem
starts with a procedure call in the Ada source code of the Ada.Calendar
package.
This is the definition of that procedure in Ada source code:
type time_t is
range -(2 ** (Standard'Address_Size - Integer'(1))) ..
+(2 ** (Standard'Address_Size - Integer'(1)) - 1);
type time_t_Pointer is access all time_t;
procedure localtime_tzoff
(timer : time_t_Pointer;
is_historic : int_Pointer;
off : long_Pointer);
pragma Import (C, localtime_tzoff, "__gnat_localtime_tzoff");
__gnat_localtime_tzoff is implemented in a C file named sysdep.c
and starts like this:
void
__gnat_localtime_tzoff (const time_t *timer, const int *is_historic, long *off)
There is an implicit assumption here that the time_t type
defined in the Ada source code and the C time_t are the same size.
The latest version of the MinGW C runtime breaks that assumption -
it has both 32- and 64-bit time_t types; the 64-bit time_t
is the default, but the 32-bit version can be selected by using a
#define _USE_32BIT_TIME_T directive.
The result of the default is that the Ada procedure call feeds a
32-bit value to the C routine which expects a 64-bit value, with
predictably disastrous consequences.
There ate two possible quick-and-dirty patches that would fix the
problem for the MinGW binary distribution.
1. use #define _USE_32BIT_TIME_T
2. change "const time t *timer" to "const int *timer", with the
appropriate patches in the body of the procedure to convert the
int value to a time_t value where needed.
Neither of these are appropriate for a patch to be submitted
to the GCC maintainers - they are not 64-bit clean.
I need a bit of information about the philosophy governing
patches to the GCC Ada runtime source code. It appears to me
that the idea is to confine system-dependent code and patches to
the C side in sysdep.c and leave the Ada source code identical
for all platforms, so that a proposed patch that modifies the Ada
code would be rejected.
A confirmation of this philosophy will be useful to me when
discussing this issue with the MinGW developers.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-11-15 23:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-15 23:20 A problem with the Ada.Calendar runtime package as implemented by the MinGW project David Gressett
2013-11-16 0:16 ` David Gressett
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).