On Feb 17, 2009, at 10:50 PM, John Malmberg wrote:
I have not yet figured out how to fix this, but the localtime64_r
wrapper seems to only sometimes call the vms.c localtime, and
gmtime64_r is configured to never call it. This is done by logic in
time64_config.h which is not modified by the VMS Configure.com
procedure.
Yes, there is currently no way to turn off the time64 stuff entirely
but it might be better to try to get it working than to create
configuration options to disable it.
These routines need to always call the wrappers in vms.c,
That may not be the best approach as I think you'd no longer get the
extended range provided by the time64 versions.
or those routines need additional logic for VMS, as there is a
vmsish time pragma that controls if the time functions results are
in UTC or localtime.
That's probably better and shouldn't be too intrusive. I think it
would just be a matter of putting something like
# ifdef VMSISH_TIME
if (VMSISH_TIME) when = _toutc(when); /* Input was local time */
# endif
in two or three places. The _toutc and _toloc macros would need to be
moved from vms.c to vmsish.h and given somewhat more collision-proof
names.
This is causing the failure in the vmsish.t module where it is
requesting a gmtime() return of a time value that is in local time,
not GMT.
Thanks for the report. The other problem with time64 and friends is
that the build falls down hard on any platform that does not have a 64-
bit integer type. Possibly OpenVMS VAX is the only one of those
that's been somewhat recently supported. I've started looking into
making it use a double, but that may involve understanding more of how
time64 works than I care to or have time to in the near term.
________________________________________
Craig A. Berry
mailto:craigbe...@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
