At 11:29 AM -0600 2/3/05, John E. Malmberg wrote: >On Wed, 2 Feb 2005, Craig A. Berry wrote: > >> At 2:41 PM -0600 2/2/05, John E. Malmberg wrote: >> >I notice that Perl is checking if the stat is being done on the NULL >> >device, and generating a fake stat structure. >> > >> >stat() should return the correct information from either a filespec of >> >"NLA0:" or "NL:" or even "/dev/null" >> >> Sure, on recent versions of VMS. I'd be reluctant to break older >> versions, at least without knowing exactly which ones I was breaking >> so I could document it. > >It may more be a case of only conditionally compiling the code in for >versions of VMS older than what it is know to work for.
Yes, that would be great to cut out the cruft conditionally. I suspect 7.0 or thereabouts is where this got fixed. I can test back to 7.1. >Any idea what the oldest version of VMS that the current release of >Perl will still build on? HP/COMPAQ/DECC is avaialable in one flavor >or another back to OpenVMS 5.5-2. I would not be surprised if we could still build pretty easiliy on 6.x and even 5.5 with a little work. There would be many test failures as extensions now bundled with the core make assumptions that weren't true 10 years ago. A recent only a small handful of test failures on an unpatched Alpha v7.1, which is pretty good considering that something like seven or eight years old now. >With OpenVMS 8.2 and when using the standard compliant stat structure, >the code handling the NULL device is producing the wrong answer. Go ahead and conditionalize it out when __CRTL_VER is older than the earliest version you can easily test with or find documented in CRTL ECOs: 7.2, 7.3, or whatever. If we can move the version number back at some point, so much the better, but not a priority since the workaround does work on all pre-8.2 versions as far as I know. >In looking at what it would take to use the standard stat structure in >Perl, the only stumbling block I am seeing is the routine Perl_cando(). > >With the standard compliant stat, there is no pointer to the device name, >instead a unique 64 bit number for the st_dev member is returned, and >I am currently ignorant of anyway to use that to determine the real device >name as Perl_cando() needs. > >Until that is resolved, building Perl with _USE_STD_STAT will not work >right. Ah, good, we can also conditionalize out the encode_dev() hack, which has served us well for years but shouldn't be necessary with the new stat structure if I understand what you are saying. The reason that Perl_cando() uses the device name from the stat structure is that lib$fid_to_name returns a device name that may not be up to snuff. For example, it will return DISK$USER as the device name if the volume label is USER even if DISK$USER has been overriden by an outer mode logical. I'm not sure if that helps, and I'm not sure what to suggest about st_devnam. >And with the _LARGEFILE option, mystat might as well use __ino64_t for >the ino_type and not use the rvn and fill members. Hmm. I'll try to look at that sometime. Is that only when _USE_STD_STAT is in effect, or regardless? > >Also, the dbgminiperl.exe is not being LINKED/DEBUG, should it be? >Now I have to use LINK/DEBUG before running the build. What do you see when you do $ search config.sh vmsdebug config_args='-"Dusedevel" -"Dusevmsdebug" -"des"' usevmsdebug='define' in your top-level build directory? If you didn't configure for the debugger but just passed the __DEBUG__ macro to MMS, that may explain what you are seeing (maybe not, but that's the first thing I'd check). -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
