From david@cantrell.org.uk

--
David Cantrell, Chief Plumber, UK2

From david@cantrell.org.uk

Created by david@cantrell.org.uk

Reply-To​: david@​cantrell.org.uk
Subject​: Changed behaviour in UNIVERSAL​::can
From​: david@​cantrell.org.uk
Message-Id​: <5.18.0_18370_1371475591@​hlagh>
Cc​: david@​cantrell.org.uk
To​: perlbug@​perl.org

This is a bug report for perl from david@​cantrell.org.uk,
generated with the help of perlbug 1.39 running under perl 5.18.0.

-----------------------------------------------------------------

UNIVERSAL​::can's behaviour has changed between perl 5.16.3 and perl
5.18.0 in how it treats classes that have never been seen before.
This code​:

#!/bin/sh
perl -E 'say ">".UNIVERSAL​::can("Foo", "can")'
perl -E 'say ">".Foo->can("can")'
perl -E 'package Foo;package main;say ">".UNIVERSAL​::can("Foo", "can")'
perl -E 'package Foo;package main;say ">".Foo->can("can")'

does the following with perl 5.16.3​:

CODE(0x19e0e58)
CODE(0xa60e58)

and this with 5.18.0​:

CODE(0x248b090)
CODE(0x2135090)
CODE(0x1cd5090)
CODE(0x145d090)

As you can see, UNIVERSAL​::can("Foo", "can") and Foo->can("can") only
return a sub-ref in 5.16.3 if the Foo package has already been seen.

This change broke Params​::Validate​::Dependencies and no doubt breaks
other stuff too. Also it appears to be undocumented, including in
perldelta.

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.18.0:

Configured by david at Mon Jun 17 13:55:19 BST 2013.

Summary of my perl5 (revision 5 version 18 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=3.0.0-32-generic, archname=x86_64-linux-thread-multi
    uname='linux hlagh 3.0.0-32-generic #51-ubuntu smp thu mar 21 15:50:59 utc 2013 x86_64 x86_64 x86_64 gnulinux '
    config_args='-de -Duse64bitall -Dusethreads -Dprefix=/home/david/perl-5.18.0'
    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 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.6.1', 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 =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.18.0:
    /home/david/perl-5.18.0/lib/site_perl/5.18.0/x86_64-linux-thread-multi
    /home/david/perl-5.18.0/lib/site_perl/5.18.0
    /home/david/perl-5.18.0/lib/5.18.0/x86_64-linux-thread-multi
    /home/david/perl-5.18.0/lib/5.18.0
    .


Environment for perl 5.18.0:
    HOME=/home/david
    LANG=en_GB.UTF-8
    LANGUAGE=en_GB:en
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @cpansprout

On Mon Jun 17 06​:38​:19 2013, david@​cantrell.org.uk wrote​:

UNIVERSAL​::can's behaviour has changed between perl 5.16.3 and perl
5.18.0 in how it treats classes that have never been seen before.
This code​:

#!/bin/sh
perl -E 'say ">".UNIVERSAL​::can("Foo", "can")'
perl -E 'say ">".Foo->can("can")'
perl -E 'package Foo;package main;say ">".UNIVERSAL​::can("Foo", "can")'
perl -E 'package Foo;package main;say ">".Foo->can("can")'

does the following with perl 5.16.3​:

CODE(0x19e0e58)
CODE(0xa60e58)

and this with 5.18.0​:

CODE(0x248b090)
CODE(0x2135090)
CODE(0x1cd5090)
CODE(0x145d090)

As you can see, UNIVERSAL​::can("Foo", "can") and Foo->can("can") only
return a sub-ref in 5.16.3 if the Foo package has already been seen.

Not exactly. It was not consistent​:

$ perl -E'package Foo​::Bar; say Foo->can("can")'
CODE(0x1f4a220)

This change broke Params​::Validate​::Dependencies and no doubt breaks
other stuff too.

I’m not so surprised it broke things, but it was never self-consistent
anyway.

Also it appears to be undocumented, including in
perldelta.

It’s this entry​:

=item *

C<< $class->can >>, C<< $class->isa >>, and C<< $class->DOES >> now return
correct results, regardless of whether that package referred to by C<$class>
exists [perl #47113].

It should probably have gone under Incompatible Changes.

See https://rt-archive.perl.org/perl5/Ticket/Display.html?id=47113 for the discussion.

I don’t think there is much we can do about it at this stage.

--

Father Chrysostomos

The RT System itself - Status changed from 'new' to 'open'

From david@cantrell.org.uk

On Mon, Jun 17, 2013 at 08​:25​:33AM -0700, Father Chrysostomos via RT wrote​:

On Mon Jun 17 06​:38​:19 2013, david@​cantrell.org.uk wrote​:

...
As you can see, UNIVERSAL​::can("Foo", "can") and Foo->can("can") only
return a sub-ref in 5.16.3 if the Foo package has already been seen.
Not exactly. It was not consistent​:

$ perl -E'package Foo​::Bar; say Foo->can("can")'
CODE(0x1f4a220)

Eeuuww, that's nasty.

Also it appears to be undocumented, including in
perldelta.

It???s this entry​:

=item *

C<< $class->can >>, C<< $class->isa >>, and C<< $class->DOES >> now return
correct results, regardless of whether that package referred to by C<$class>
exists [perl #47113].

Ah, OK, I was searching for the wrong keyword.

I don???t think there is much we can do about it at this stage.

Fair enough.

--
David Cantrell | Official London Perl Mongers Bad Influence

Please stop rolling your Jargon Dice and explain the problem
you are having to me in plain English, using small words.
  -- John Hardin, in the Monastery

@cpansprout - Status changed from 'open' to 'rejected'