Craig A. Berry wrote:
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.
As I understand it, when using the DEC/Compaq/HP VMS C compiler,
currently time_t is by default an unsigned type, which avoids the Y2038
issue.
I do not know how far back that goes. All my VAX systems have been
powered off since my move, and I have not had time to get them going.
I do not know if DeathRow would be willing to host a build environment
for PERL on their VAX, or even if it has enough space.
On Alpha/I64, when the _USE_STD_STAT feature is enabled, several of the
structures that use time_t values have padding in them to handle a
future 64 bit time_t value.
The only issue with using a double to hold a time_t value may show up in
other places in Perl if it ever tries to copy that value into an integer
value.
I was told that while X/Open standard does not seem to prohibit a time_t
value from being a double, in practice it is very easy to find programs
that break if time_t values are not integer types.
So if a double is used to hold the time_t value, it probably needs to be
a perl private type. Which means it could also be a structure holding
two Integer values. I have not checked to see if a double on VAX will
lose seconds for the upper time ranges anticipated.
-John
wb8...@qsl.net
Personal Opinion Only
