public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).