in reply to Strange behaviour (bug?) of use strict 'subs' (was: ... strict 'vars')

Mh, funny.
# condition will not be true but raises no error if (defined foo) { print ref(foo); }; # raises an error as foo is marked as sub die "strange .." if foo() eq 'bar'; # also die "strange .." if (foo() eq 'bar'); # and even this does not show up _any_ errors or warnings #!/usr/bin/perl -w use strict; use diagnostics; . . . print ref(foo); # So is foo something special ? # No, no error or warning also # when replacing above line simply with print ref(bar);
So, I have no idea either what perl is assuming here.
I am using ActiveState Perl on Windows 2000 Prof., all latest MS patches applied (as per 23rd June 2002):
Summary of my perl5 (revision 5 version 6 subversion 1) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=define usemultiplicity=def
ine
    useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -
DHAVE_DES_FCRYPT  -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READ
FIX',
    optimize='-O1 -MD -DNDEBUG',
    cppflags='-DWIN32'
    ccversion='', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize
=4
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -release  -libpath:"C:\Programme\
Perl\lib\CORE"  -machine:x86'
    libpth="C:\Programme\Perl\lib\CORE"
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32
.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uuid.lib wsoc
k32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  comd
lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uuid.lib
wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release  -libpath:"C:
\Programme\Perl\lib\CORE"  -machine:x86'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT PERL_IMP
LICIT_SYS
  Locally applied patches:
        ActivePerl Build 631
  Built under MSWin32
  Compiled at Jan  2 2002 17:16:22
  @INC:
    C:/Programme/Perl/lib
    C:/Programme/Perl/site/lib
    .
Sorry for the long dump of 'perl -V' :-)

Have a nice day
All decision is left to your taste
Update
Changed title to ".. use strict" as it seems not clear which pragma is conflicted, could be strict 'refs' as well
Update 2
even more funny, as this is different from particle's command line call in the use of -m instead of -M.

C:\web\>perl -w -mstrict -e"my %f;++@f{qw/1 2/};die'ack'if foo eq 'bar';"
Unquoted string "foo" may clash with future reserved word at -e line 1.

Just to show why I think that it's not clear which pragma is conflicted. :-)
addendumAristotle is correct, as here the strict pragma does not import any pragmas and is disabled. So at least its a prove as he said.

Replies are listed 'Best First'.
Re^2: Strange behaviour (bug?) of use strict
by Aristotle (Chancellor) on Jun 23, 2002 at 14:00 UTC
    No, it's not. -m equates to use MODULE qw(); (see perlrun) which means -mstrict disables all strictures. Further, it actually demonstrates that it is the subs stricture that is conflicted, because enabling it causes Perl to skip the (then obviously redundant) bareword warnings.

    Makeshifts last the longest.