From aaron@caxton.com

The following program does not generate an error.

use strict;
$a=1;
$b=1;

Using $c will generate an error. My guess is that this has to do with
the $a and $b used by sort. Perhaps the behavior should be left alone
if existing scripts will stop working. But, at the least, a note should
be added to the use strict documentation.

This perlbug was built using Perl 5.00503 - Wed Oct 27 13:46:39 EDT 1999
It is being executed now by  Perl 5.00503 - Wed Oct 27 13:46:39 EDT 1999

Site configuration information for perl 5.00503:

Configured by jsinger at Wed Oct 27 09:57:46 EDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos hunter 5.5.1 generic_103640-17 sun4m sparc '
    hint=recommended, useposix=true, d_sigaction=define
    bincompat3=n useperlio=undef d_sfio=undef
  Compiler:
    cc='gcc-2.8.0', optimize='-O', gccversion=2.8.0
    cppflags='-I/usr/local/include -I/usr/gnu/include'
    ccflags ='-I/usr/local/include -I/usr/gnu/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    voidflags=15, castflags=0, d_casti32=define, d_castneg=define
    intsize=4, alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='gcc-2.8.0', ldflags =' -L/usr/local/lib -L/usr/gnu/lib'
    libpth=/usr/local/lib /usr/gnu/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -lgdbm -ldl -lm -lc -lcrypt
    libc=/lib/libc.so, so=so
    useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fpic', lddlflags='-G -L/usr/local/lib -L/usr/gnu/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /usr/gnu/lib/perl5/sun4-solaris/5.00503
    /usr/gnu/lib/perl5
    /usr/gnu/lib/perl5/site_perl/sun4-solaris
    /usr/gnu/lib/perl5/site_perl
    .


Environment for perl 5.00503:
    HOME=/home/atlantic/aaron
    LANG=en_US
    LANGUAGE (unset)
    LC_COLLATE=en_US
    LC_CTYPE=en_US
    LC_MESSAGES=C
    LC_MONETARY=en_US
    LC_NUMERIC=en_US
    LC_TIME=en_US
    LD_LIBRARY_PATH=/usr/local/lib:/usr/sybase/lib:/usr/openwin/lib:/usr/local/rvplayer
    LOGDIR (unset)
    PATH=/eatDvmt/bin:/eatProd/bin:/home/atlantic/aaron/bin:/usr/dt/bin/:/usr/openwin/bin:/usr/openwin/demo:/bin:/usr/bin:/usr/ucb:/usr/ccs/bin:/usr/sbin:/usr/games/:/usr/newprint/bin/:/spt/shell/sh:/usr/local/bin:/usr/local/bin/X11:/usr/gnu/bin:/usr/sybase/bin:/usr/local/office51/bin
    PERL_BADLANG (unset)
    SHELL=/usr/gnu/bin/bash

From [Unknown Contact. See original ticket]

The following program does not generate an error.

use strict;
$a=1;
$b=1;

Using $c will generate an error.

Do we have some statistics on the ten most frequently submitted non-bugs ?
Maybe it would make sense to have perlbug list them before accepting input ?

My guess is that this has to do with
the $a and $b used by sort. Perhaps the behavior should be left alone
if existing scripts will stop working. But, at the least, a note should
be added to the use strict documentation.

That could be true, but I am unsure. In any case the following patch
applies to strict.pm 1.01. It is probably not the right wording, but should
this be considered useful/necessary, it might make the job easier for
someone better at this than I am.

--- ./perl/lib/strict.pm	Tue Dec 07 20:34:16 1999
+++ ./perl/lib/strict-patch.pm	Tue Dec 07 21:13:56 1999
@@ -71,10 +71,26 @@
 
 
 =back
 
-See L<perlmodlib/Pragmatic Modules>.
+=head1 CAVEATS
+
+This pragma will I<not> catch undeclared variables that Perl itself sets or
+uses (eg. C<$_> and friends, all the C<$^x> variables, C<@INC>... See
+L<perlvar> for more). In most cases, it is certainly a good thing as declaring
+them wouldn't make sense. However there are a few occurences where it might
+bite you back, most notably with C<$a> and C<$b> which are needed by

+
+=head1 SEE ALSO
+
+See L<perlmodlib/Pragmatic Modules>.

=cut

$strict​::VERSION = "1.01";

.Robin
Radioactive cats have 18 half-lives.

From [Unknown Contact. See original ticket]

Robin Berjon <robin@​knowscape.com> wrote

That could be true, but I am unsure. In any case the following patch
applies to strict.pm 1.01. It is probably not the right wording, but should
this be considered useful/necessary, it might make the job easier for
someone better at this than I am.

Errr.. You seem to have overlooked

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-12/msg00009.html

where I sent a patch in response to the last time this was reported.

Mike Guy

From [Unknown Contact. See original ticket]

At 18​:55 09/12/1999 +0000, M.J.T. Guy wrote​:

Robin Berjon <robin@​knowscape.com> wrote

That could be true, but I am unsure. In any case the following patch
applies to strict.pm 1.01. It is probably not the right wording, but should
this be considered useful/necessary, it might make the job easier for
someone better at this than I am.

Errr.. You seem to have overlooked

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-12/msg00009.html

where I sent a patch in response to the last time this was reported.

Well, overlooked is not the exact word I would use. I did search the
archives, but apparently not using anything that had this come up :)

.Robin
You can tune a piano, but you can't tuna fish.