Front page | perl.perl5.porters |
Postings from March 2023
Re: refaliasing disrespects readonlyness of array or hash
Thread Previous
|
Thread Next
From:
demerphq
Date:
March 25, 2023 16:39
Subject:
Re: refaliasing disrespects readonlyness of array or hash
Message ID:
CANgJU+V3G=pFGzE_y6my74yTO037C7dQd=R8eghjQ5G=9bGJnA@mail.gmail.com
On Fri, 24 Mar 2023 at 09:14, Zefram via perl5-porters
<perl5-porters@perl.org> wrote:
>
> demerphq wrote:
> >I think it is better to avoid making judgements like this until you
> >actually know what code is involved.
>
> The issue isn't that it's a lot of core code, but the extent of the
> code written in Perl that could potentially be affected. local has been
> around for a long time, including the ability to localise elements of a
> read-only container. More of an issue for arrays than hashes, though,
> I think, because restricted hashes aren't quite so old or widely used.
>
> >Needs tests, but it pretty much works afaict:
> >
> >https://github.com/Perl/perl5/pull/20963
>
> That prevents unpermitted changes being made by the inward phase of
> localisation, but it's still possible for the restoration to make an
> unpermitted change if the hash became more restricted during the scope
> of the localisation:
>
> $ perl -lwe '%a=qw(a z c d); { local $a{a} = "b"; Internals::SvREADONLY(%a, 1); Internals::SvREADONLY($a{a}, 1); print %a; } print %a'
> cdab
> cdaz
I dont see a problem here. The local is ending and we are putting it
back to the original state. I dont think it matters that the new value
is readonly.
> There's some question about the legitimacy of that particular test case:
> local specifically supplies a mutable scalar, and is the user implicitly
> promising not to make it readonly? In general I think it's legitimate
> to make a thing readonly after a mutable construction phase, and in this
> case that goes for both the hash and the scalar. But I don't have a
> feel for what sort of things ought to be possible with a restricted hash.
> I find them a very weird concept, especially in the way that mutability
> of the hash container depends on mutability of the scalar object that
> it contains.
AFAIK they were invented to get rid of pseudo-hashes, which themselves
were an attempt to make it possible to detect mistyped keys in a hash
based OO model. I think they are basically a failed experiment,
except that every time I say that someone pops up and says "but I like
them". :-(
> There are many other permutations to consider. A particularly neat one,
> because it doesn't require any explicit readonly flag setting within
> the local scope, comes from combining local and refaliasing:
>
> $ perl -Mexperimental=refaliasing,declared_refs -lwe '%a=qw(a z c d); Internals::SvREADONLY(%a, 1); { local \$a{a} = \"b"; print %a; } print %a'
> abcd
> azcd
The one is also fine, as the value is not readonly when the
localization happens.
>
> It's arguable that that one is a distinct bug. If one makes sense of a
> restricted hash by saying that the readonlyness of the element scalars is
> semantically part of the container, then it is wrong for refaliasing to
> be willing to put a readonly scalar into such a hash, whether localised
> or not. But that's probably the wrong view of restricted hashes.
I think there is a real danger of overthinking this.
Nothing says that unlocalizing a value that has been marked as
readonly is illegal, and IMO if we did consider it illegal it would be
pretty confusing, so lets simply NOT do that. On the other hand,
double localizing the value once it has been marked as readonly should
be illegal, and with my patch is illegal. On the other hand, it seems
that given a read-only value is not allowed to be updated or deleted,
it also shouldn't be allowed to be localized. Which my patch prevents
So I dont think there is any controversy here. All we need to do is
prevent aliases and localization from touching a read-only value in a
restricted hash.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next