FORTRAN interface to CRTL functions

[Michael Menge]

VMS V8.4, Fortran V8.2 and C V7.3 on Alpha:

I want to call the CRTL function
struc tm *gmtime (const time_t timer);
from a Fortran program. I tried some versions (with/without INTERFACE, EXTERNAL etc.) but didn't find the right one. For debugging purpose I wrote a dummy c-function ggtime
struc tm *ggtime (const time_t timer);
with only a printf() for the argument timer to be able to see what Fortran is passing to the c-function.
Defining in Fortran the c-function as a subroutine or an INT*4 function (only to debug the argument), the printf() shows the right value; Fortran puts the argument in the first position of the argument list and returns the function value per register.
But defining the c-function as a TYPE, the argument list is built different (the return value or its address is put somewhere in the argument list), so the c-function doesn't get the correct argument and printf() show a wrong value. The argument lists for a Fortran TYPE function and a c struc function differs right?
Do I have to build a wrapper c subroutine or can I build the right interface to the c function in Fortran directly (via !DEC$ ATTRIBUTES etc.)?
Calling the CRTL function
time_t mktime (struc tm *timeptr)
from Fortran via decc$mktime works fine, the argument list matches between Fortran and C (tm is passed by reference as the first argument, time_t is passed back as integer*4 in the r0 register).

[Joseph Huber_1]

This one, using an interface to gmtime_r as a subroutine seems to work:

===============================================
Program test_gmtime
USE tm_type

INTERFACE
! FUNCTION gmtime_f(t,tm_p)
SUBROUTINE gmtime_f(t,tm_p)
USE tm_type
INTEGER , INTENT(IN) :: t
type(TM), INTENT(OUT) :: tm_p
! type(TM) , pointer :: gmtime_f
! END FUNCTION
END subroutine
END INTERFACE

type (TM) :: tm_p
type (TM), pointer :: tm_r

! tm_r=gmtime_f(0,tm_p)
call gmtime_f(0,tm_p)

print *, ' ',tm_p%tm_year,tm_p%tm_mon,tm_p%tm_mday,tm_p%tm_hour,tm_p%tm_min
END program test_gmtime
=============================================
! where gmtime_f.c is:
#include
struct tm *gmtime_f (const time_t *timer, struct tm *result) {
return gmtime_r (timer,result);
}
=============================================
tm_type module is:

MODULE TM_TYPE
PUBLIC
TYPE :: TM
INTEGER tm_sec ! seconds after the minute [0, 61]
INTEGER tm_min ! minutes after the hour [0, 59]
INTEGER tm_hour ! hours since midnight [0, 23]
INTEGER tm_mday ! day of the month [1, 31]
INTEGER tm_mon ! months since January [0, 11]
INTEGER tm_year ! years since 1900
INTEGER tm_wday ! days since Sunday [0, 6]
INTEGER tm_yday ! days since January 1 [0, 365]
INTEGER tm_isdst ! Daylight Saving Time flag
INTEGER tm_gmtoff ! offset from UTC in seconds
INTEGER fill1 !to account for newer struct tm
INTEGER fill2
END TYPE TM
END MODULE TM_TYPE

=============================================

But the version to use gmtime as a function returning a pointer to type TM seems not to work:
Either my pointer assignement syntax is wrong , or F90 pointer types are not compatible with C pointers.

integer,pointer:: probably is not the same as
c_intptr_t in iso_c_binding.

[Joseph Huber_1]

And to the question if Fortran(90) can use a C function returning a pointer: it apparently is not VMS specific. It needs ISO_C_BINDING, see this discussion:
http://stackoverflow.com/questions/3852790/fortran-interface-to-call-a-c-function-that-return-a-pointer

(and no, VMS Fortran 8.2 does not yet have iso_c_binding, no?)

[Joseph Huber_1]

A Fortran 2003 version would probably look like:

PROGRAM test_gmtime
USE tm_type
USE, intrinsic :: iso_c_binding, only : c_ptr,c_f_pointer

IMPLICIT NONE

INTERFACE
FUNCTION gmtime_f(t,tm_p)
USE, intrinsic :: iso_c_binding, only : c_ptr
USE tm_type
INTEGER , INTENT(IN) :: t
type(TM), INTENT(OUT) :: tm_p
type(c_ptr) :: gmtime_f
END FUNCTION
END INTERFACE

type (TM) :: tm_p
type (TM), pointer :: tm_r
type(c_ptr) :: c_p

c_p= gmtime_f(0,tm_p)
call c_f_pointer(c_p, tm_r) !convert C- to Fortran-pointer
print *, ' ',tm_p%tm_year,tm_p%tm_mon,tm_p%tm_mday,tm_p%tm_hour,tm_p%tm_min
print *, ' ',tm_r%tm_year,tm_r%tm_mon,tm_r%tm_mday,tm_r%tm_hour,tm_r%tm_min
END PROGRAM test_gmtime

The c_f_pointer call makes the difference!

[Joseph Huber_1]

I just made a test of the F2003 version on
GNU Fortran (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]

and it works perfectly, returning the tm structure both in the passed argument structure, and in the returned C pointer to a tm structure.

Remember the difference between C pointers and Fortran POINTER type:
C pointers in practice are simply addresses,
while Fortran POINTER types are opaque structures. They contain the address of the pointee, the association status, and probably in addition some description of type and size.

[Joseph Huber_1 · Accepted solution]

>Do I have to build a wrapper c subroutine or >can I build the right interface to the c >function in Fortran directly (via !DEC$ >ATTRIBUTES etc.)?

yes, that's why I wrapped it in gmtime_f.
The reason is, that decc$gmtime(_r) exists in CRTL, but apparently returns nothing.
Looking into time.h, it shows that gmtime_r is effectively defined as either
__utc_gmtime(_r) or
__utc_localtime_(r)
depending on some macro definitions.

[Michael Menge]

For the VMS part we are using VMS Fortran V8.2, so there isn't any ISO_C_BINDING right?
As mentioned the c-function decc$mktime works fine with fortran and returns the time_t value(INTEGER*4) in the same way as a fortran function. I wonder in which way the c-compiler returns the tm pointer as the function result?
For the fortran pointer is an opaque structure and not the same as a c pointer, perhaps the fortran POINTER statement POINTER (tm_p,tm) could be used. This kind of pointer works like in c and is also available on our other platform SLES with the inter compiler.
Also when using the !DEC$ atttribute C directive for the c funtion name in the fortran interface definition, the compiler should be able to handle the return value of the c function in the correct manner.

[Joseph Huber_1]

[
As mentioned the c-function decc$mktime works fine with fortran and returns the time_t value(INTEGER*4) in the same way as a fortran function. I wonder in which way the c-compiler returns the tm pointer as the function result?
]

For scalars (integer,real,logical) it is not a problem, C and Fortran return the value in a register.
C also returns pointers simply in a register (an address).

If You like dirty programming, then You can declare the C function simply as INTEGER*4 or INTEGER*8 and pass the function return value as an argument to another subroutine/function expecting a pointer to a structure or array.
This is basically what iso_c_binding provides in subroutine c_f_pointer.


[
For the fortran pointer is an opaque structure and not the same as a c pointer, perhaps the fortran POINTER statement POINTER (tm_p,tm) could be used. This kind
of pointer works like in c and is also available on our other platform SLES with the inter compiler.
]

This is the old pre-f90 non-standard type of pointer (called "Cray pointers", because it stems from Cray-Fortran).
I doubt is is directly compatable with C pointer return, but if You tested it, so be it...

[
Also when using the !DEC$ atttribute C directive for the c funtion name in the fortran interface definition, the compiler should be able to handle the return value of the c function in the correct manner.
]

Maybe, but then again without iso_c_binding the result is nothing but some integer type containing an address, You can pass the value to procedures as above, but can't use it as a F90 POINTER type without a conversion routine like c_f_pointer().

In the case of gmtime_r it is not necessary.
For other kind of C RTL functions such a kind of bricolage might be necessary; although I find it much more cleaner to write a Fortran wrapper, e.g. in the style of the Posix Fortran IPXF* and PXF* routines, which pass everything as subroutine arguments, not via function return.

Some of my examples:
http://www.mpp.mpg.de/~huber/util/
see *PXF* and *_f source files.

[Hoff]

I'd suggest implementing this with the Sun or GNU Fortran gmtime intrinsic interface:

http://gcc.gnu.org/onlinedocs/gfortran/GMTIME.html

This if somebody doesn't already have that coded and posted somewhere, given Sun and GNU Fortran code does tend to get ported around to other Fortran compilers.

If this is a more generic request for a time value for logging or such, then there are system services and RTL calls that can and do fetch values useful for timestamps, including sys$getutc and friends.

[Joseph Huber_1]

[ GNU Fortran GMTIME ]

Yes of course, that's exactly what my gmtime_f is for VMS:
call gmtime_f(0,tm_p)

I just named it differently, because it could conflict with gmtime, if linked to the VAXC RTL.

In my first reply I just added a F90 INTERFACE, one can use it without, and instead of the TM type one can simply pass an integer array in F77.

[Ph Vouters]

Hi Michael,

If you consider the technical articles at http://vouters.dyndns.org/tima/Linux-Fortran-Internationalizing_messages.html and http://vouters.dyndns.org/tima/OpenVMS-Fortran-Internationalizing_messages.html perform exactly the same. However my HP Fortran for OpenVMS not recognizing ISO_C_BINDING, the VMS solution to this problem is entirely OpenVMS dependant. This is no matter of the VMS CRTL often prefixing its routines with DECC$.

In the hope this can give you some clues.
Philippe

[Joseph Huber_1]

In general I would discourage direct calls of decc$* routines (except the ones documented in CRTL help): You never know what macros the C compiler is defining/expecting/using.
See this example:

program test_ctime
character*32 ct
integer t
integer decc$time
external decc$time

t=0
call CTIME_F(t,ct)
print *,' t=',t,' ',ct

print *,' using time_f():'
call time_f(t)
call CTIME_F(t,ct)
print *,' t=',t,' ',ct

print *,' using decc$time():'
t=decc$time()
call CTIME_F(t,ct)
print *,' t=',t,' ',ct
end


Where time_f.c and ctime_f.c are the wrapper routines at
http://www.mpp.mpg.de/~huber/util/

fortran test_ctime
link test_ctime
show time
5-FEB-2011 21:17:07
run test_ctime
t= 0 Thu Jan 1 01:00:00 1970
using time_f():
t= 1296937035 Sat Feb 5 21:17:15 2011
using decc$time():
t= 1296940635 Sat Feb 5 22:17:15 2011
Observe the different values for t !

There are even more discrepancies when mktime() comes into play:

http://www.mpp.mpg.de/~huber/util/tests/test_mktime.for

[Joseph Huber_1]

mktime e.g. needs

#define _DECC_V4_SOURCE
#define _VMS_V6_SOURCE
#define _TM_LONG
#define USE_GMTOFF /* seems always to give the correct offset*/
#define __USE_XOPEN 1
#define _XOPEN_SOURCE
#define __TM_USE_UTC_TIME

to produce the right result:

sh time
6-FEB-2011 10:54:56
run test_mktime
1296989699 ctime_f(decc$time()):
Sun Feb 6 11:54:59 2011

1296989699 ctime_f(decc$mktime(gmtime_f(decc$time(),tm))):
Sun Feb 6 11:54:59 2011

1296989699 ctime_f(mktime_f(gmtime_f(decc$time(),tm))):
Sun Feb 6 11:54:59 2011

1296986099 ctime_f(time_f()):
Sun Feb 6 10:54:59 2011

1296986099 ctime_f(mktime_f(gmtime_f(time_f(),tm))):
Sun Feb 6 10:54:59 2011

The results of ctime() should match the VMS show time, they do not if decc$ calls are used without wrappers!

Without that definition,
ctime_f(mktime_f(gmtime_f(time_f(),tm)))
is not the same as
ctime_f(time_f())

So again, direct calls to decc$time,decc$gmtime,decc$mktime do not produce the correct results.

[Michael Menge]

Is there an explanation for the different seconds from time() and decc$time() (missing/other c-macros active) or is it a bug? A call to decc$crtl_init() gives the same results.

[Joseph Huber_1]

Have a look into
If not the behaviour of VMS before V7 is requested by macros like _DECC_V4_SOURCE and _VMS_V6_SOURCE (see HELP CRTL TIME FUNCTION_VAR), then a C time() call uses an __UTC_* entry point. The DECC_V4/VMS_V6* macros would result in time_t to be calculated from local VMS time, resulting in 1 hour difference in my (MET) case, which seems to be the case for direct calls to decc$time().

Other differences come from compiling gmtime(_r) with or without the __TM_USE_UTC_TIME and *GMTOFF* macros.
Interestingly I need to compile mktime with the _V4_/_V6_ macros to have the above chain of
ctime(time())
giving the same result as
ctime(mktime(gmtime(time(),tm))),

but this may be due to the old VMS/DECC version combination I have.

[Michael Menge]

decc$localtime_r returns GMT time and
decc$gmtime_r returns (as mentioned) only 0:
program test
integer tm(0:10),scnds
scnds = 1301184000 ! 2011-03-27T00:00:00Z
tm = 0
call decc$gmtime_r (scnds,tm)
print *, 'gmt', scnds, tm
tm = 0
call decc$localtime_r (scnds,tm)
print *, 'local', scnds, tm

scnds = 1301194800 ! 2011-03-27T03:00:00Z
tm = 0
call decc$gmtime_r (scnds,tm)
print *, 'gmt', scnds, tm
tm = 0
call decc$localtime_r (scnds,tm)
print *, 'local', scnds, tm
end

Isn't it a bug for decc$gmtime_r returning nothing or are there any hints not to use it?

[Michael Menge]

Replacing decc$gmtime_r by the wrapper routine gmtime_f mentioned above and
decc$localtime_r by localtime_f.c:

#include
struc tm *localtime_f (const time_t *scnds, struc tm *result)
{
return localtime_r (scnds, result);
}

gives the correct results.

[Joseph Huber_1]

> decc$localtime_r returns GMT time and
but -as the name indicates- should return local time.


>decc$gmtime_r returns (as mentioned) only 0:
>Isn't it a bug for decc$gmtime_r returning >nothing or are there any hints not to use it?

There are no hints not only not to use it, but also no hints to use it.

Since direct calls to decc$* are not documented, all is speculation and mood.

[Ph Vouters]

For the record. HP Fortran for OpenVMS solution. Next time write a corresponding C program and $ cc/list/machine to know which DECC$ entry points the HP C compiler uses.

$ fortran/source_form=free/debug/noopt gmtime.f90
$ link gmtime
$ run gmtime
tm%tm_sec= 21
tm%tm_min= 18
tm%tm_hour= 11
tm%tm_mday= 9
tm%tm_mon= 111
tm%tm_wday= 9
tm%tm_yday= 39
tm%tm_isdst= 0
$ type gmtime.f90
program gmtime
implicit none
integer(kind=4) t0;
integer(kind=4) tm_ptr;
external print_tm, decc$perror
integer(kind=4),external :: decc$__utc_time ,decc$__utctz_gmtime

t0=decc$__utc_time(%val(0))
tm_ptr=decc$__utctz_gmtime(%ref(t0))
if (tm_ptr .eq. 0) then
call decc$perror(%ref('gmtime'))
stop
endif
call print_tm(%val(tm_ptr))
stop
end

subroutine print_tm(tm)
implicit none
type tm_t
integer(kind=4) tm_sec
integer(kind=4) tm_min
integer(kind=4) tm_hour
integer(kind=4) tm_mday
integer(kind=4) tm_mon
integer(kind=4) tm_year
integer(kind=4) tm_wday
integer(kind=4) tm_yday
integer(kind=4) tm_isdst
integer(kind=4) tm_gmtoff
integer(kind=4) tm_zone
end type tm_t
type (tm_t) tm

print *,"tm%tm_sec=",tm%tm_sec
print *,"tm%tm_min=",tm%tm_min
print *,"tm%tm_hour=",tm%tm_hour
print *,"tm%tm_mday=",tm%tm_mday
print *,"tm%tm_mon=",tm%tm_year
print *,"tm%tm_wday=",tm%tm_mday
print *,"tm%tm_yday=",tm%tm_yday
print *,"tm%tm_isdst=",tm%tm_isdst
return
end

[Ph Vouters]

Michael,

The full solution is documented at http://vouters.dyndns.org/tima/OpenVMS-Fortran-time-gmtime-Calling_time_and_gtime_in_Fortran_OpenVMS.html
Yours truly,
Philippe

[Michael Menge]

I have made a call to HP:
decc$gmtime_r returns null, decc$localtime_r returns MGT-time. From C, gmtimes works fine (local time is MEZ = UTC + 1).

Here the answer from engineering:

We have following update:
We are able to reproduce the problem. During analysis, we noticed that when we invoke CRTL routines gmtime_r and localtime_r from FORTRAN program, the functions related to local time based model is being considered. On observing the function definition for gmtime_r within local time based model, we noticed that the function gmtime_r just returns NULL. Hence the output of gmtime_r was inappropriate.
However when these functions are invoked in a C Program, they are considering UTC based time model and hence are generating appropriate output.
As a workaround, we could get the gmtime & localtime by invoking decc$__utctz_gmtime_r and decc$__utctz_localtime_r routines instead of decc$gmtime_r/decc$localtime_r routines respectively.
Meanwhile we will check with CRTL team and get back to you on this.

[Joseph Huber_1]

I think that the gmtime_r returning NULL is a real bug and should be corrected.

But for the rest of local/UTC based time handling, I vote strongly against CRTL changing its behaviour:
the default implementation calls the correct decc$utc... entry points, while the decc$gmtime,decc$localtime etc. entries are called if explicitly the "old" behaviour is wanted.
From the CRTL help for gmtime,localtime and other time related functions:

Compiling with the _DECC_V4_SOURCE and _VMS_V6_SOURCE feature-
test macros defined enables a local-time-based entry point to
this function that is equivalent to the behavior before OpenVMS
Version 7.0.

So changing the decc$ entries would break existing software.

As I have told in earlier replies, user programs simply should not call directly the time related DECC$ entry points, but rather write a C wrapper!

Calling decc$localtime(_r) or decc$gmtime(_r) is equivalent to
#define _VMS_V6_SOURCE
and the using localtime/gmtime.

See as an example
http://www.mpp.mpg.de/~huber/util/localtime_f.C

Compile it with /define=(TEST)
and /define=(TEST,_VMS_V6_SOURCE)
to see the difference.

[Ian Miller.]

Just to muddy the waters further there is also the DTS routines

http://h71000.www7.hp.com/doc/84final/4493/4493pro_016.html#port_api

[Joseph Huber_1]

The DTS routines have their own internal binary time (128 bit UTC).
But converting between all of VMS quad/time_t/struct tm/utc_t requires use of a consistent set of C time calls, which is not guaranteed by using direct decc$* calls.

I have put together all my time related routines on my web-page:

http://www.mpp.mpg.de/~huber/util/time.html

I tested them to be sure that all conversions reproduce the same result in both directions.

[WW304289]

Joseph Huber wrote:
> I think that the gmtime_r returning NULL is a real bug and should be corrected.

I disagree. The gmtime[_r] functions returning NULL are called by programs compiled with _VMS_V6_SOURCE macro defined (or when called explicitly as decc$gmtime[_r]). This macro indicates, among other things, that the system does not support UTC, so, it is only logical (at least to me) that functions like gmtime[_r] fail. What can be considered a bug is that the functions fail without setting errno. In this case ENOTSUP would be appropriate, I believe.

What's definitely a bug is that UTC-based gmtime succeeds, but sets errno. The following was obtained on OpenVMS IA64 V8.3:

$ pipe cc x.c ; link x.obj ; run x.exe
gmtime: no such file or directory
54BD8
$

x.c
---
#include
#include
#include

int main() {
time_t t = time(0);
struct tm *tms;

errno = 0;
tms = gmtime(&t);
perror("gmtime");
printf("%p\n", tms);
}
$