Craig A. Berry wrote:
At 10:35 PM -0400 8/22/05, John E. Malmberg wrote:
On every blead perl I have seen, the following bug is present on
VMS and is causing the script t/op/magic.t to fail at test 7.
In the Perl debugger, before running any script if you issue the
command 'x keys(%ENV), the entry for index 0, also shows up as index 1.
DB<1> x keys(%ENV)
0 'SYS$TIMEZONE_DAYLIGHT_SAVING'
1 'SYS$TIMEZONE_DAYLIGHT_SAVING'
2 'CDE$DETACHED_LOGICALS'
3 'MOP$NAMED_LOAD'
4 'BUILD_ROOT'
On all subsequent calls, you get the expected results:
DB<2> x keys(%ENV)
0 'SYS$TIMEZONE_DAYLIGHT_SAVING'
1 'CDE$DETACHED_LOGICALS'
2 'MOP$NAMED_LOAD'
3 'BUILD_ROOT'
4 'SMBSRVSHR_TV'
If you're feeling brave, fire up the VMS debugger and step through
prime_env_iter() in [.vms]vms.c. It spawns a process to run SHOW
LOGICAL * and then parses the output. If you don't see the first one
doubled in there, then it must have something to do with how the
cache is accessed the first time, probably in hv.c.
I have fired up the VMS debugger. The output is not doubled. Also, the
show logical output is not in the same order.
What I have not learned how to do in the VMS debugger is how to look at
what data type that Perl is looking at.
The prime_env_iter() only does any real work the first time it is called.
Since it works the second time, I am trying to figure out what is
different between the first time and subsequent times.
It appears that the absolute first time that keys() or values() or
each() is called a pointer to the first element is not advancing, but
after that everything is fine.
Currently I do not know what variable or structure holds that element so
I can track it's initial value and it's changes.
-John
[EMAIL PROTECTED]
Personal Opinion Only
