[perl #17571] slight package name irregularity
Marc Lehmann
# Please include the string: [perl #17571]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17571 >
This is a bug report for perl from ro...@cerebro.laendle,
generated with the help of perlbug 1.34 running under perl v5.8.0.
-----------------------------------------------------------------
[Please enter your report here]
The package statement accepts package names with trailing "::" without removing them, so
package test::;
die __PACKAGE__;
outputs "test::", which imho is not expected (writing "bless $ref, test::"
for example will remove the extra "::" at the end).
In my opinion either the package statement should rmeove the extra "::"'s,
or it should be a syntax error.
[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=low
---
Site configuration information for perl v5.8.0:
Configured by root at Sat Jul 20 01:25:22 CEST 2002.
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4, archname=i686-linux
uname='linux cerebro 2.4.18-pre8-ac3 #2 smp tue feb 5 17:35:23 cet 2002 i686 unknown '
config_args=''
hint=previous, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler:
cc='gcc-2.95.4', ccflags ='-I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-Os -funroll-loops -mcpu=pentium -march=pentium -g',
cppflags='-I/opt/include -D_GNU_SOURCE -I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
ccversion='', gccversion='2.95.4 20010319 (prerelease)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc-2.95.4', ldflags =''
libpth=/usr/lib /opt/lib
libs=-lcrypt -ldl -lm -lc
perllibs=-lcrypt -ldl -lm -lc
libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.2.5'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared'
Locally applied patches:
---
@INC for perl v5.8.0:
/root/src/sex
/opt/perl/lib/perl5
/opt/perl/lib/perl5
/opt/perl/lib/perl5
/opt/perl/lib/perl5
.
---
Environment for perl v5.8.0:
HOME=/root
LANG (unset)
LANGUAGE (unset)
LC_CTYPE=de_DE@euro
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/root/s2:/root/s:/opt/qt/bin:/bin:/usr/bin:/usr/app/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/app/bin:/usr/app/sbin:/usr/X11/bin:/opt/j2sdk1.4.0_01//bin:/opt/bin:/opt/sbin:.:/root/cc/dejagnu/bin
PERL5LIB=/root/src/sex
PERLDB_OPTS=ornaments=0
PERL_BADLANG (unset)
SHELL=/bin/bash
Rafael Garcia-Suarez
>
> The package statement accepts package names with trailing "::" without removing them, so
>
> package test::;
>
> die __PACKAGE__;
>
> outputs "test::", which imho is not expected (writing "bless $ref, test::"
> for example will remove the extra "::" at the end).
>
> In my opinion either the package statement should rmeove the extra "::"'s,
> or it should be a syntax error.
I prefer the first suggestion.
Consider also :
$ perl -le 'print bless{},"foo::"'
foo::=HASH(0x810ba34)
$ perl -le 'print bless{},foo::'
foo=HASH(0x810ba34)
I think that both should return the same result.
Bart Schuller
> $ perl -le 'print bless{},"foo::"'
> foo::=HASH(0x810ba34)
> $ perl -le 'print bless{},foo::'
> foo=HASH(0x810ba34)
>
> I think that both should return the same result.
It's always been possible to bless into an arbitrary string:
$ perl -le 'print bless{},"<>:&%$#@"'
<>:&%@=HASH(0x813796c)
Although I personally would have no problems if it were changed to check
for valid (potential) package names.
--
Bart.
Rafael Garcia-Suarez
It's kind of a valid package name :
#!perl
*{'<>:&%@::foo'}=sub { print "hello\n" };
$x = bless {}, '<>:&%@';
$x->foo(); # this prints hello
__END__
The question is : should perl remove trailing colons from the 2nd
string argument to bless ? I think it should. Currently the following :
sub foo { print "hello\n" }
$x = bless {}, 'main::';
$x->foo();
fails with
Can't locate object method "foo" via package "main::" at x line 3.
Mike Guy
> The package statement accepts package names with trailing "::"
> without removing them, so
>
> package test::;
>
> die __PACKAGE__;
>
> outputs "test::", which imho is not expected
It's entirely to be expected. Null fields are entirely legitimate
in variable names, and therefore in package names. Consider
for example $::x (which is the same as $main::x) or $Class::, which
is the symbol table for Class.
> (writing "bless $ref, test::"
> for example will remove the extra "::" at the end).
That's rather misleading. Watch:
DB<1> x bless [], 'test:'
0 test:=ARRAY(0x202504)
empty array
DB<2> x bless [],'test::'
0 test::=ARRAY(0x1de714)
empty array
DB<3> x bless [],test::
0 test=ARRAY(0x1de7a4)
empty array
DB<4>
It's not the bless() that's removing the '::' (and it would be totally
wrong if bless() did). Rather it's some odddity with bareword processing:
DB<1> x test::
0 'test'
DB<2>
[ Incidentally, there seems to be something odd in the debugger here.
Why doesn't this complain?
DB<2> x use strict;temp::
0 'temp'
DB<3> ]
Bart Schuller <schu...@lunatech.com> wrote
> It's always been possible to bless into an arbitrary string:
>
> $ perl -le 'print bless{},"<>:&%$#@"'
> <>:&%@=HASH(0x813796c)
>
> Although I personally would have no problems if it were changed to check
> for valid (potential) package names.
That would break all sorts of things. For better or worse, variable
names, and therefore package names, are arbitrary strings. Though in
general you can only access them with symbolic references.
And bless *does* check if you give it a classname argument rather than a
string:
perl -we 'use strict; print bless [], test::'
Bareword "test::" refers to nonexistent package at -e line 1.
temp=ARRAY(0xf196c)
Mike Guy