At 12:43 PM -0400 4/2/06, John E. Malmberg wrote: >Craig A. Berry wrote: >> >>I finally got around to testing this, and there are a few problems with it. >> >>1.) We can no longer compile on pre-7.3 systems because the call to >>the CRTL utime() is done regardless of CRTL version. We need to make >>sure that on pre-7.3 systems we use the old home-grown code that >>fiddles with the FIB. > >I meant to use the HAVE_UTIME_H macro conditionally compile this in.
Yeah, that makes sense, so it will track with what's in vmsish.h. > >>2.) The code as written does not handle a null second argument to >>utime() and accvios if it gets one. Null is valid (and quite common >>because it means "use the current time") and needs to be handled. > >I missed that. Apparently while common, it is not tested in the Perl self >tests. It is tested in [.t.io]fs.t. But since we were never using the new code unless DECC$EFS_CHARSET was defined, I hadn't seen the failure. > >>3.) I can't think of any relationship between DECC$EFS_CHARSET and >>utime. Perhaps this was supposed to be DECC$EFS_FILE_TIMESTAMPS ? >>Even here, though, I don't think we need to do anything differently >>because the CRTL utime() is going to do its own feature checking. > >The ACP interface that is used for the work around to not having a built in >utime() can not handle EFS file specifications. It needs to have the on-disk >file specification. But won't do_rmsexpand() take care of that? > >>I've attached my working patch, but I'm also not sure if we are doing >>the UTC translation in the right direction, so I need to study that a >>bit more. > >The utime() call always expects it's parameters to be in UTC, so when the >pragma is set to use local time, the local time needs to be converted to UTC. That sounds right. I don't think we test this aspect of utime() in the test suite, but we probably should. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
