strict.pm not strict enough

[p5pRT]

Migrated from rt.perl.org#2036 (status was 'resolved')

Searchable as RT2036$

[p5pRT]

From gbacon@itsc.uah.edu

A post on clpmisc today contained something like

  #! /usr/bin/perl -w
  use strict

  $, = ' '; # set output field separator
  $\ = "\n"; # set output record separator

  $foo = 42;

That shouldn't compile, right? Notice that there's no comma after
C<use strict>. The code above is equivalent to C<use strict ' '>
which fails to enable any stricture! It's because of the following
line in &strict​::bits​:

  foreach my $s (@​_){ $bits |= $bitmask{$s} || 0; };

IOW, C<use strict 'foobletch';> is a nop. I can see how one might
construe this as a backward compatibility feature, but if a programmer
casts a spell of protection, Perl ought to thump back for using false
magic.

This is also the case for 5.00503.

Perl Info

Site configuration information for perl 5.00563:

Configured by gbacon at Fri Jan 14 19:47:37 CST 2000.

Summary of my perl5 (revision 5.0 version 5 subversion 63) configuration:
  Platform:
    osname=linux, osvers=2.2.5-15, archname=i686-linux
    uname='linux ruby.itsc.uah.edu 2.2.5-15 #1 mon apr 19 23:00:46 edt 1999 i686 unknown '
    config_args='-des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
    cppflags='-Dbool=char -DHAS_BOOL -fno-strict-aliasing -I/usr/local/include'
    ccflags ='-Dbool=char -DHAS_BOOL -fno-strict-aliasing -I/usr/local/include'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=/lib/libc-2.1.1.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00563:
    /usr/local/lib/perl5/5.00563/i686-linux
    /usr/local/lib/perl5/5.00563
    /usr/local/lib/site_perl/5.00563/i686-linux
    /usr/local/lib/site_perl
    .


Environment for perl 5.00563:
    HOME=/home/gbacon
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/nmh/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/usr/local/jdk1.2/bin:/home/gbacon/bin
    PERL_BADLANG (unset)
    SHELL=/bin/tcsh

[p5pRT]

From [Unknown Contact. See original ticket]

In message <200001252125.PAA01722@​ruby.itsc.uah.edu>,
  Greg Bacon writes​:

: Notice that there's no comma after C<use strict>.

Errr.. s/comma/semicolon/

Greg

[p5pRT]

From [Unknown Contact. See original ticket]

See <URL​:http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg01175.html>

This should also apply against 5.00503's strict.pm.

[6​:49] ruby% diff -u strict.pm.63 strict.pm

Inline Patch

--- strict.pm.63        Wed Jan 26 06:40:54 2000
+++ strict.pm   Wed Jan 26 06:49:18 2000
@@ -19,8 +19,8 @@
 
 If no import list is supplied, all possible restrictions are assumed.
 (This is the safest mode to operate in, but is sometimes too strict for
-casual programming.)  Currently, there are three possible things to be
-strict about:  "subs", "vars", and "refs".
+casual programming.)  Currently, there are three possible strictures:
+"subs", "vars", and "refs".
 
 =over 6
 
@@ -90,7 +90,15 @@
 
 sub bits {
     my $bits = 0;
-    foreach my $s (@_){ $bits |= $bitmask{$s} || 0; };
+    foreach my $s (@_) {
+        if ($bitmask{$s}) {
+            $bits |= $bitmask{$s};
+        }
+        else {
+            require Carp;
+            Carp::carp("Unknown stricture `$s'");
+        }
+    }
     $bits;
 }
End of Patch.

[p5pRT]

From @jhi

use strict 'use strict'? :-)

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

[p5pRT]

From [Unknown Contact. See original ticket]

Greg Bacon <gbacon@​itsc.uah.edu> wrote

IOW, C<use strict 'foobletch';> is a nop. I can see how one might
construe this as a backward compatibility feature, but if a programmer
casts a spell of protection, Perl ought to thump back for using false
magic.

This is a deliberate feature - see the last time this was discussed
on p5p. The reasob is so you can write in your module

  use strict 'new_feature_introduced_in_perl6';

and still have the module usable under perl5 (but without the new check
of course).

Mike Guy

[p5pRT]

From [Unknown Contact. See original ticket]

Greg Bacon <gbacon@​itsc.uah.edu> wrote
  [ patch for strict.pm ]

Don't do that - see my previous message.

A check that the argument was a valid word might be a good idea, tho'.
That would cause no compatibility problems, and would catch the case
you originally quoted.

Mike Guy

[p5pRT]

From [Unknown Contact. See original ticket]

This is a deliberate feature - see the last time this was discussed
on p5p. The reasob is so you can write in your module

use strict 'new\_feature\_introduced\_in\_perl6';

and still have the module usable under perl5 (but without the new check
of course).

I like this for​:

  use less 'whitespace';
  use less 'pain';

Sadly, I can't seem to make

  use fewer 'keystrokes';
  use fewer 'declarations';

work right. :-)

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

In message <E12DXpx-0005qe-00@​ursa.cus.cam.ac.uk>,
  "M.J.T. Guy" writes​:

: A check that the argument was a valid word might be a good idea, tho'.
: That would cause no compatibility problems, and would catch the case
: you originally quoted.

There is no compatibility problem. It spits out a warning. Regardless
of the course of action, we need a little consistency. The version of
warnings.pm in 5.5.630 croaks when it sees an unrecognized option.
Both pragmata should behave in the same way.

Greg

[p5pRT]

From The RT System itself

Consensus appears to be not to change this. Closing.