Front page | perl.perl5.porters |
Postings from November 2003
>>I've done a bit more digging, and this is failing because in 5.6.1 I was
>>setting the keys & values of the tied hashes to be readonly, and this has
>>clashed with the way the 'Restricted hash' functionality introduced
>>post-5.6.1 which also uses the READONLY flags. The implementation of
>>restricted hashes isn't exactly clearly documented on perlguts, so I haven't
>>yet figured out exactly what I am doing wrong. I'm setting/unsetting
>>READONLY on the hashes themselves, and on the entries returned by
>>hv_fetch(), but obviously this isn't correct. I'm getting the SEGV in
>>Perl_hv_clear, here:
>>
>> I32 i;
>> HE* entry;
>> for (i = 0; i <= (I32) xhv->xhv_max; i++) {
>>---> entry = ((HE**)xhv->xhv_array)[i];
>>
>>because xhv->xhv_array is NULL - I have no idea why yet. Can anyone shed
>>any light on exactly how the READONLY flags are supposed to be set to get
>>the various restricted hash behaviours?
>
> It is _reasonably_ intuitive - my memory is:
>
> If you set SvREADONLY on the HV then
> the keys become fixed - you can't add anything and if you delete
> the hash entry remains with value being a place-holder value.
>
> AFAIK the SvREADONLY of the SVs returned from FETCH are not special.
$ perl -MHash::Util=lock_keys -e 'my %h; lock_keys(%h); %h=();'
Segmentation Fault(coredump)
We've been discussing this on IRC this morning, and I have a patch in
progress - once I have verified it I'll mail it in. If you look at hv.c,
the SvREADONLy block show above doesn't check for xhv->xhv_array being NULL,
yet further down it does this:
if (xhv->xhv_array /* HvARRAY(hv) */)
(void)memzero(xhv->xhv_array /* HvARRAY(hv) */,
(xhv->xhv_max+1 /* HvMAX(hv)+1 */) * sizeof(HE*));
So clearly it *is* valid for xhv->xhv_array to be NULL.
I'm also going to relocate the guts of Internals::hv_clear_placeholder into
core so that it can be more easily used by XSUB code that wishes to use
restricted hashes - the fact that most of the code is comments explaining
what is going on suggests that it is unlikely that XSUB authors will get
this right if they try to 'roll their own'. I'll be submitting that as a
seperate patch.
--
Alan Burlison
--
Thread Previous
|
Thread Next