develooper Front page | perl.perl5.porters | Postings from October 2011

Re: [perl #102464] is warning valid?

Thread Previous | Thread Next
From:
Brian Fraser
Date:
October 29, 2011 05:55
Subject:
Re: [perl #102464] is warning valid?
Message ID:
CA+nL+nahrHF=JDLGCxWf5tdmu7FqTX6EBLKwOL3AD5CZzP67QA@mail.gmail.com
On Sat, Oct 29, 2011 at 8:59 AM, Linda Walsh <perlbug-followup@perl.org>wrote:

> # New Ticket Created by  Linda Walsh
> # Please include the string:  [perl #102464]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=102464 >
>
>
>
> This is a bug report for perl from perl-diddler@tlinx.org,
> generated with the help of perlbug 1.39 running under perl 5.12.3.
>
>
> -----------------------------------------------------------------
> [Please describe your issue here]
>
> To be honest, I'm not even sure this is a real bug, or is be
> design, but it seems counterintuive.
>
> if I test a variable for being 'defined' :
>
>        if (defined($foo)) {
>                print "foo=$foo\n";
>        }
>
>
>        Should I, even under strict (which is the case), get:
>
> Global symbol "$foo" requires explicit package name at -e line 3.
> Execution of -e aborted due to compilation errors.
>
>
> I can understand *why* it happens, but *should* it happen?
> I.e. in the above example, that "$foo" isn't defined is not a
> 'design error' and it not being defined is checked for, preventing
> it's use.  So should it cause a "parse-time" error?
>
> Not a common case or that important, but it just seemed 'off'...
>
>
> But it also might be the case that's more work than it is
> worth to correct it...?
>
> C'est la vie!... ;-)
>
>
> an error
> and is checked for"$foo" has no need to be defined --
>
> Should it be an error if the variable is I mean should I get the error if
> it is in
>
>
> [Please do not change anything below this line]
> -----------------------------------------------------------------
> ---
> Flags:
>    category=core
>    severity=low
> ---
> This perlbug was built using Perl 5.12.3 - Fri May  6 13:31:41 UTC 2011
> It is being executed now by  Perl 5.12.3 - Fri May  6 13:26:30 UTC 2011.
>
> Site configuration information for perl 5.12.3:
>
> Configured by abuild at Fri May  6 13:26:30 UTC 2011.
>
> Summary of my perl5 (revision 5 version 12 subversion 3) configuration:
>
>  Platform:
>    osname=linux, osvers=2.6.36, archname=x86_64-linux-thread-multi
>    uname='linux build33 2.6.36 #1 smp 2011-02-21 10:34:10 +0100 x86_64
> x86_64 x86_64 gnulinux '
>    config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr
> -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm
> -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -Wall -pipe
> -Accflags=-DPERL_USE_SAFE_PUTENV'
>    hint=recommended, useposix=true, d_sigaction=define
>    useithreads=define, usemultiplicity=define
>    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>    use64bitint=define, use64bitall=define, uselongdouble=undef
>    usemymalloc=n, bincompat5005=undef
>  Compiler:
>    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
> -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64',
>    optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
> -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall
> -pipe',
>    cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING
> -fno-strict-aliasing -pipe -fstack-protector'
>    ccversion='', gccversion='4.5.1 20101208 [gcc-4_5-branch revision
> 167585]', gccosandvers=''
>    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
>    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
>    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
>    alignbytes=8, prototype=define
>  Linker and Libraries:
>    ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
>    libpth=/lib64 /usr/lib64 /usr/local/lib64
>    libs=-lm -ldl -lcrypt -lpthread
>    perllibs=-lm -ldl -lcrypt -lpthread
>    libc=/lib64/libc-2.11.3.so, so=so, useshrplib=true, libperl=libperl.so
>    gnulibc_version='2.11.3'
>  Dynamic Linking:
>    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
> -Wl,-rpath,/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE'
>    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64
> -fstack-protector'
>
> Locally applied patches:
>
>
> ---
> @INC for perl 5.12.3:
>    /usr/lib/perl5/site_perl/5.12.3/x86_64-linux-thread-multi
>    /usr/lib/perl5/site_perl/5.12.3
>    /usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi
>    /usr/lib/perl5/vendor_perl/5.12.3
>    /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi
>    /usr/lib/perl5/5.12.3
>    .
>
> ---
> Environment for perl 5.12.3:
>    HOME=/home/law
>    LANG=en_US.UTF-8
>    LANGUAGE (unset)
>    LC_CTYPE=en_US.UTF-8
>    LD_LIBRARY_PATH (unset)
>    LOGDIR (unset)
>
>  PATH=.:/sbin:/usr/local/sbin:/opt/lsb/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin
>    PERL_BADLANG (unset)
>    SHELL=/bin/bash
>
>
The general use case for defined[*] is whenever something stored inside a
variable is not undef, not whenever the variable itself exists. Doing the
latter would encourage people to use, say, symbolic references instead of
hashes, so it seems like a bad idea.

Certainly there's stuff like defined &func which throw the above out of the
window, but that's an exception to the rule. If you want to know whenever a
global is defined or not, you could do something like
defined ${ \our $foo }
(However, that adds foo to the current package's symbol table, so perhaps
something like
exists $::{__PACKAGE__} && exists ${ __PACKAGE__ . "::" }{foo}
&& *{__PACKAGE__ . "::foo"}{VARTYPE} && defined ${*{__PACKAGE__ .
"::foo"}{VARTYPE}}
...which needs even more massaging if __PACKAGE__ has multiple parts, but
you get the idea.)

There's unfortunately no built-in to check if a lexical variable exists in
the current scope, though it's possible to roll your own if you don't mind
using a bit of XS (see pad_findmy in perlapi and/or the CvPADLIST macro, or
PadWalker in CPAN for a more backwards-compatible solution). But the real
question here is, why would you want to do that? Are you trying to sue a
variable as a variable name? If so, please read
http://perl.plover.com/varvarname.html and consider using a hash instead.

[*] defined @array and defined %hash being deprecated for a reason.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About