Closed p5pRT closed 21 years ago
I just spent the better part of an hour wondering why a redefine error wouldn't go away. It was caused by me doing a:
no strict 'redefine';
rather than a:
no warnings 'redefine';
but strict.pm didn't complain\, so I never realised that it was there where the error was.
Included is a patch that should cause the above to warn with:
Don't know how to "no strict qw(redefine)"
A patch for the test is also attached.
Attachment includes an improved version of the test patch. It now also checks "use strict 'garbage'" and "use/no strict qw(foo bar)".
Liz
Elizabeth Mattijsen (via RT) \perlbug@​perl\.org wrote: [ C\< no strict 'redefine'; > doesn't complain. ]
:Included is a patch that should cause the above to warn with: : : Don't know how to "no strict qw(redefine)"
As I remember it\, this behaviour was deliberate so that if we added additional optional strictures in the future you could take advantage of them without your code breaking under older perls.
I'm not sure how relevant that approach still is; I'll put this patch in for now\, with the proviso that it may come out again before 5.10.
Hugo
Elizabeth Mattijsen (via RT) \perlbug@​perl\.org wrote: :Included is a patch that should cause the above to warn with: : : Don't know how to "no strict qw(redefine)"
Thanks\, this and the additional tests patch applied as #17869.
A few minor points for patches: - please try to be strict in your use of standard formatting and whitespace - please supply diffs relative to the top level perl directory or higher - please don't supply components of a single change as multiple attachments; do that only if the changes are distinctly separate from each other - please try to make sure that tests print "not ok" if they fail
Cheers\,
Hugo
Elizabeth Mattijsen (via RT) \perlbug@​perl\.org wrote: :Included is a patch that should cause the above to warn with: : : Don't know how to "no strict qw(redefine)"
Hmm\, this causes a failure in ext/Storable/t/code.t\, I think because it is using a Safe compartment that thinks it knows everything a 'use strict qw/ refs /' can do. It's not clear to me what the fault is here.
Hugo
hv@crypt.org wrote: :Elizabeth Mattijsen (via RT) \perlbug@​perl\.org wrote: ::Included is a patch that should cause the above to warn with: :: :: Don't know how to "no strict qw(redefine)" : :Hmm\, this causes a failure in ext/Storable/t/code.t\, I think :because it is using a Safe compartment that thinks it knows :everything a 'use strict qw/ refs /' can do. It's not clear to :me what the fault is here.
I've temporarily changed the core Storable to skip those tests until we sort this out\, as change #17872.
Hugo
On Sun\, Sep 08\, 2002 at 05:57:44PM +0100\, hv@crypt.org wrote:
- please try to make sure that tests print "not ok" if they fail
File/Find/t/find.t tests 1 and 2 are doubly naughty
1: they don't print not ok if they fail 2: they happily print ok several times if they find more copies of the file than they expect. This causes t/TEST to report a test failure at test 189 (one after the last test) which is somewhat confusing.
The appended patch cures both of these. I chose to use a package global rather than a lexical as it seemed the intent of the first two tests was to be simple\, and relying on lexical variables in closures (instead of simple anonymous subroutines) didn't feel "simple"
I wasn't sure if the whole test should assimilated by Test::More-of-borg\, but I thought I'd leave a patch to the usual suspect :-)
Or maybe it should use the $case code.
Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
I wasn't sure if the whole test should assimilated by Test::More-of-borg\, but I thought I'd leave a patch to the usual suspect :-)
As far as I'm concerned\, anything that uses funcs to print test results rather than hardcoded ok/not ok and test counts is a step in the right direction....
-- 'Andy Lester andy@petdance.com Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//\,$&) [unpack'C*'\,"n2]3%+>\"34.'%&.'^%4+!o.'"])
hv@crypt.org writes:
Elizabeth Mattijsen (via RT) \perlbug@​perl\.org wrote: :Included is a patch that should cause the above to warn with: : : Don't know how to "no strict qw(redefine)"
Hmm\, this causes a failure in ext/Storable/t/code.t\, I think because it is using a Safe compartment that thinks it knows everything a 'use strict qw/ refs /' can do. It's not clear to me what the fault is here.
With the strict.pm patch\, "use strict" will fail in a safe compartment if ":still_to_be_decided" or "caller" in not in the permitted opset. Try this script with and without the strict.pm patch:
use Safe; $s = new Safe; $s->permit(qw(:default require)); $s->reval("use strict; 1") or die $@; __END__
Nevertheless\, here a patch for the code.t test if the strict.pm patch won't be retracted:
Slaven Rezic - slaven.rezic@berlin.de babybike - routeplanner for cyclists in Berlin handheld (e.g. Compaq iPAQ with Linux) version of bbbike http://bbbike.sourceforge.net
On Sun\, Sep 08\, 2002 at 02:50:39PM +0100\, hv@crypt.org wrote:
Elizabeth Mattijsen (via RT) \perlbug@​perl\.org wrote: [ C\< no strict 'redefine'; > doesn't complain. ]
:Included is a patch that should cause the above to warn with: : : Don't know how to "no strict qw(redefine)"
As I remember it\, this behaviour was deliberate so that if we added additional optional strictures in the future you could take advantage of them without your code breaking under older perls.
no strict 'strict'; use strict qw(refs vars future whatever);
?
or a lexical warning that defaults to fatal and on? [strict.pm would only need to require warnings if someone used a category other than the current three]
I think that would need another bit in $^H - are they in short supply?
Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
At 02:50 PM 9/8/02 +0100\, hv@crypt.org wrote:
Elizabeth Mattijsen (via RT) \perlbug@​perl\.org wrote: [ C\< no strict 'redefine'; > doesn't complain. ] :Included is a patch that should cause the above to warn with: : Don't know how to "no strict qw(redefine)" As I remember it\, this behaviour was deliberate so that if we added additional optional strictures in the future you could take advantage of them without your code breaking under older perls.
Maybe the croak() would need to be changed to a warn() then? So that you would at least get some feedback if there is something that is not understood?
Liz
At 10:17 PM 9/8/02 +0200\, Slaven Rezic wrote:
+ $safe->permit(qw(:default require caller));
The caller() is just in there to find out whether a "use" or "no" was being done. I could rewrite this so that this is passed as a parameter to the subroutine: this would add overhead to the common case though\, whereas the overhead now is just a single exists() on a hash.
Liz
Elizabeth Mattijsen \liz@​dijkmat\.nl wrote: :At 10:17 PM 9/8/02 +0200\, Slaven Rezic wrote: :>+ $safe->permit(qw(:default require caller)); : :The caller() is just in there to find out whether a "use" or "no" was being :done. I could rewrite this so that this is passed as a parameter to the :subroutine: this would add overhead to the common case though\, whereas the :overhead now is just a single exists() on a hash.
An alternative would be to reword the complaint so that it doesn't need to know. C\< warn "Unknown stricture '$s'"; > may even be enough.
Hugo
At 11:28 AM 9/9/02 +0100\, hv@crypt.org wrote:
Elizabeth Mattijsen \liz@​dijkmat\.nl wrote: :At 10:17 PM 9/8/02 +0200\, Slaven Rezic wrote: :>+ $safe->permit(qw(:default require caller)); :The caller() is just in there to find out whether a "use" or "no" was being :done. I could rewrite this so that this is passed as a parameter to the :subroutine: this would add overhead to the common case though\, whereas the :overhead now is just a single exists() on a hash. An alternative would be to reword the complaint so that it doesn't need to know. C\< warn "Unknown stricture '$s'"; > may even be enough.
Do you want me to submit a new patch for that?
Liz
Nicholas Clark wrote:
File/Find/t/find.t tests 1 and 2 are doubly naughty
Thanks\, patch applied as #17884.
Slaven Rezic \slaven\.rezic@​berlin\.de wrote: :With the strict.pm patch\, "use strict" will fail in a safe compartment :if ":still_to_be_decided" or "caller" in not in the permitted opset.
I've now checked in the patch below as #17986; this removes the use of 'caller' in strict.pm\, and tightens the Safe compartment in Storable's t/code.t tests to match.
I'm not sure that the wording of the error message is ideal\, but I suspect it's good enough.
Hugo ==== //depot/perl/ext/Storable/t/code.t#4 - /src/hv/perl/ext/Storable/t/code.t ==== @@ -239\,7 +239\,7 @@ { my $safe = new Safe; # because of opcodes used in "use strict": - $safe->permit(qw(:default require caller)); + $safe->permit(qw(:default require)); local $Storable::Eval = sub { $safe->reval(shift) };
$freezed = freeze $obj[0]->[1]; ==== //depot/perl/lib/strict.pm#16 - /src/hv/perl/lib/strict.pm ==== @@ -16\,12 +16\,8 @@ $bits |= $bitmask{$s} || 0; } if (@wrong) { - my $useno = { - __PACKAGE__.'::import' => 'use'\, - __PACKAGE__.'::unimport' => 'no' - }->{ (caller(1))[3] }; require Carp; - Carp::croak("Don't know how to '$useno ".__PACKAGE__." qw(@wrong)'"); + Carp::croak("Unknown 'strict' tag(s) '@wrong'"); } $bits; } ==== //depot/perl/lib/strict.t#7 - /src/hv/perl/lib/strict.t ==== @@ -100\,17 +100\,17 @@ }
eval qq(use strict 'garbage'); -print +($@ =~ /^Don't know how to 'use strict qw\(garbage\)/) +print +($@ =~ /^Unknown 'strict' tag\(s\) 'garbage'/) ? "ok ".++$i."\n" : "not ok ".++$i."\t# $@";
eval qq(no strict 'garbage'); -print +($@ =~ /^Don't know how to 'no strict qw\(garbage\)/) +print +($@ =~ /^Unknown 'strict' tag\(s\) 'garbage'/) ? "ok ".++$i."\n" : "not ok ".++$i."\t# $@";
eval qq(use strict qw(foo bar)); -print +($@ =~ /^Don't know how to 'use strict qw\(foo bar\)/) +print +($@ =~ /^Unknown 'strict' tag\(s\) 'foo bar'/) ? "ok ".++$i."\n" : "not ok ".++$i."\t# $@";
eval qq(no strict qw(foo bar)); -print +($@ =~ /^Don't know how to 'no strict qw\(foo bar\)/) +print +($@ =~ /^Unknown 'strict' tag\(s\) 'foo bar'/) ? "ok ".++$i."\n" : "not ok ".++$i."\t# $@";
hv@crypt.org writes:
Slaven Rezic \slaven\.rezic@​berlin\.de wrote: :With the strict.pm patch\, "use strict" will fail in a safe compartment :if ":still_to_be_decided" or "caller" in not in the permitted opset.
I've now checked in the patch below as #17986; this removes the use of 'caller' in strict.pm\, and tightens the Safe compartment in Storable's t/code.t tests to match.
I'm not sure that the wording of the error message is ideal\, but I suspect it's good enough.
Thanks\, and you can add this (documentation) patch:
Slaven Rezic - slaven.rezic@berlin.de
Berlin Perl Mongers - http://berliner.pm.org
Slaven Rezic \slaven\.rezic@​berlin\.de wrote: :hv@crypt.org writes: :> I've now checked in the patch below as #17986; this removes the use of :> 'caller' in strict.pm\, and tightens the Safe compartment in Storable's :> t/code.t tests to match. [...] :Thanks\, and you can add this (documentation) patch:
Thanks\, applied as #18024.
Hugo
@jhi - Status changed from 'new' to 'resolved'
Migrated from rt.perl.org#17061 (status was 'resolved')
Searchable as RT17061$