FORTRAN interface to CRTL functions

[Joseph Huber_1]

Well, the C standard says about errno:

The value of errno is zero at program startup, but is never set to zero by any library
function.
The value of errno may be set to nonzero by a library function call
whether or not there is an error, provided the use of errno is not documented in the
description of the function in this International Standard.

VMS CRTL (and other C systems like GNU C) do not say anything about errno, so errno should not be used unless the function return value is NULL.

[WW304289]

"
The value of errno is zero at program startup, but is never set to zero by any library
function.
The value of errno may be set to nonzero by a library function call
whether or not there is an error, provided the use of errno is not documented in the
description of the function in this International Standard.
"

The use of errno by gmtime() is not documented in "this International Standard" so one can argue that setting errno by gmtime is not a violation of the C standard.

However, the use of errno by gmtime() is documented in X/Open specs. So, this is a violation of X/Open which C RTL on VMS claims to support.

Now consider the gmtime_r() function which only defined in X/Open and POSIX: it exhibits the same behavior that gmtime().

I'm pretty sure that errno is set to ENOENT when CRTL is trying to load a timezone file.

The people supporting C RTL can give us definitive answer w.r.t. standard compliance and, perhaps, comment on whether setting errno by gmtime[_r] is intentional or an oversight. Btw, the functions set errno only on first invocation which does not look like a consistent behavior of the C RTL.

-Boris

[Craig A Berry]

It's probably more a question of whether gmtime() should save and restore errno than whether it should avoid setting it on success. It probably doesn't directly set it but uses other functions that do. There are things that can go wrong with almost any way of handling it, which is why new POSIX functions are supposed to avoid errno and use specific return values for specific error conditions. Too bad no one thought of that decades ago -- oh, wait....

[Hoff]

Non-native calls directly into the C RTL have not been considered supported, at least classically.

The CRTL classically required initialization before use, there's a CRTL_INIT call in the library when the main routine was not a C main. I don't know if that's been relaxed, but the CRTL initialization call is still documented.

http://h71000.www7.hp.com/doc/83final/5763/5763pro_028.html#decc_crtl_init_routine

I don't know off-hand if that call effects the timekeeping initialization.

An alternative library that will likely remain (at least somewhat) more stable than the CRTL interfaces is the DTSS library; that's documented in the utility routines, and provides all manner of time-related calls. (I'd post a link to the Utility Routines manual, but parts of the HP web site have been glacially slow this week.)

And in general, a direct CRTL call and the rest of the baggage saves all of a few lines of C code for a local jacket, and for an approach that would not necessarily be one that will be maintained going forward. The C RTL folks have been free to shuffle their entry points behind that forest of preprocessor calls, and sometimes have. (Well, a few lines of a C jacket here, plus the CRTL initialize call somewhere earlier in the Fortran application.)

And a caveat: By calling the gmtime and friends, you're now sensitive to the C TZ and TDF logical names in your Fortran application, and the complete morass that is daylight saving time on VMS. Put another way, you can end up with values off by an hour if your UTC/TZ/TDF isn't right.

HP OpenVMS Engineering would seem better served here by adding a GMTIME call into the Fortran RTL, rather than sorting out a direct C call from Fortran. As mentioned in another reply, this Fortran call exists in other Fortran compilers, so it's not inventing a wholly new Fortran API. (Well, if it isn't now open season on direct C RTL calls...)

[Joseph Huber_1]

I can't resisty to answer to the question errno setting by gmtime_r(), I just read what the posix standard (1003.1) is saying:

=============================================
The value of errno shall be defined only after a call to a function for which it is explicitly stated to be set and until it is changed by the next function call or if the application assigns it a value. The value of errno should only be examined when it is indicated to be valid by a function's return value.
No function in this volume of IEEE Std 1003.1-2001 shall set errno to 0. The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified.
=============================================

So Posix is even more clear in stating that errno should not be used in success case unless the function description says so.
And the Posix description of gmtime_r says nothing different from the C standard: in case of error errno shall be set, it says nothing about errno in success (non-NULL) case.

The rule for library functions to never set errno to 0 even forbids the VMS implementation to reset errno if it was set by some other internal calls.

So a programmer shall not use errno after a successfull return of gmtime(_r) !

[Stanley F Quayle]

As long as we're complaining about the C RTL, I'd like to point out a feature that changed in the transition from VAX C to DEC C.

In VAX C, vaxc$errno would report the VMS status on every call to a RTL function (returning 1 for success, of course). Very useful for detecting errors and using with LIB$SIGNAL.

In DEC C, vaxc$errno holds a VMS status code sometimes when errno is changed to non-zero. (There's a special errno value that indicates that you should check vaxc$errno).

In converting a major project (>100k lines), my biggest pain was mapping errno values to something meaningful in vaxc$errno.

[Hoff]

StanQ: perror and strerror are the usual path, if you've not seen those:

here's something that some nameless body wrote up on this topic over a decade ago:

http://h71000.www7.hp.com/wizard/wiz_3017.html

You can decide to use the C message catalog or other mechanisms. I've posted some tools in the GNM stuff on the Freeware that deals with printing messages from signals and such.

The biggest issues I tend to encounter with this stuff is the general lack of UTF8 string support within the compiler, and the increasing age and availability of the required libraries and tools. But yes, message handling is pretty weak.

And before you reply, yes, I know from wchar and the rest of the Unicode zoo. I'm now using C tools that allow Unicode directly in the source files and Unicode strings, and that's definitely fun to haul over to VMS. Not.

[Ph Vouters]

More information about the 'use ISO_C_BINDING' statement. According to personal tests under Linux/Cygwin/Windows gfortran, it happens that the 'use ISO_C_BINDING' statement is only valid starting with Fortran 2003 or is only accepted using the -std=gnu switch on the gfortan command. The above is true starting with gcc4.

As OpenVMS Fortran latest accepted standard is Fortran 95, there is consequently no possibility to use such a statement.

In the hope this clarifies this topic.

[Ph Vouters]

To be complete with DECC$ symbols or any other symbols from any other shareable images that can be used under Java Native Access (JNA), JRuby, Python or any HP VMS compiled language other than HP C or HP C++, refer to http://vouters.dyndns.org/tima/OpenVMS-binutils-2.21.51-Unix_utilities-nm-strings-size-addr2line-objdump-as_on_OpenVMS.html

The example chosen at this URL is especially thought for this specific forum topic.

In the hope this will interest people.

[H.Becker]

In case you want to look into a VMS shareable image, you can use analyze/image. It shows much more information than nm. The latter just prints the "value" of the symbol, the index into the symbol vector, and flags it as A = absolute, which in VMS terms isn't absolute at all.

But you also may want to grab the imgexp tool (Google will find it for you):

$ pipe mc []imgexp sys$share:decc$shr.exe |search sys$input gmtime
DECC$GMTIME, type is procedure, value is 0xc03790
decc$gmtime, type is procedure, value is 0xc03790
DECC$__UTCTZ_GMTIME, type is procedure, value is 0xc06430
decc$__utctz_gmtime, type is procedure, value is 0xc06430
DECC$__UTC_GMTIME, type is procedure, value is 0xc074c8
decc$__utc_gmtime, type is procedure, value is 0xc074c8
DECC$GMTIME_R, type is procedure, value is 0xc08bf0
decc$gmtime_r, type is procedure, value is 0xc08bf0
DECC$__UTC_GMTIME_R, type is procedure, value is 0xc08c38
decc$__utc_gmtime_r, type is procedure, value is 0xc08c38
DECC$__UTCTZ_GMTIME_R, type is procedure, value is 0xc08c68
decc$__utctz_gmtime_r, type is procedure, value is 0xc08c68
$

Imgexp shows the code address of the procedure, which makes it obvious that some procedures do have a lowercase alias entry in the symbol vector, here.