The patch that I submitted is needed to eliminate a data corruption
issue that should be affecting more than just VMS.
If I have diagnosed this wrong, please let me know.
In VMS this data corruption is only visible in one apparent test script
where it causes Perl to exit with an access violation after a pointer
gets stepped on. So it is easy to see how it might get missed.
What I have found after Nicholas Clark pointed me in the right
direction, is that in this case is that the allocation size for the
sv_u.svu_array member appears to be too small.
The size of the allocated or reallocated array is controlled by the
xhv_max member.
DBG> exam hv->sv_any->xhv_max
HV\Perl_hv_iternext_flags\hv->sv_any->xhv_max: 7
The actual calculation is for the array size =
PERL_HV_ARRAY_ALLOC_BYTES(HvMAX(hv) + 1) + sizeof(struct xpvfhv_aux)
HvMAX(hv) = 7 from above.
So PERL_HV_ARRAY_ALLOC_BYTES results in:
(8 * sizeof(HE*) + sizeof(struct xpvfhv_aux)
The size of a Pointer type on VMS is 4 bytes. And the size of the
struct xpvfhv is 12 bytes. This results in (8 * 4) + 12 or 48 bytes.
A pointer to the xpvfhv is then stored in hv->sv_u.svu_array[8].
The size of the svu_array type is 12 bytes, so the offset is 12 * (8-1)
is 84 which is a bit beyond the 48 bytes that was allocated.
It appears to me that macro PERL_HV_ARRAY_ALLOC_BYTES should be using
the size of the HE structure instead of the size of a pointer to that
structure.
If that were the calculation, than 108 bytes would have been allocated
or reallocated for the array member, which looks like the correct size.
-John
[EMAIL PROTECTED]
Personal Opinion Only
