From pcg@goof.com

Created by root@cerebro.laendle

the following code snippet​:

=============================================================================
use overload '""' => sub { "Can" };
 
$x = bless {};
 
print "\$x is '$x'\n";
print "\$x does not start with 'Can'\n" if $x !~ /^Can/;
print "\$x is still '$x'\n";

Prints (here)​:

  $x is 'Can'
  $x does not start with 'Can'
  $x is still 'Can'

But I would expect to see only the first and last lines. Replacing the first line
by​:

  use overload '""' => sub { print "stringification\n"; "Can" };

Gives​:

  stringification
  $x is 'Can'
  stringification
  $x does not start with 'Can'
  stringification
  $x is still 'Can'

So my ""-overload is indeed being called. Sorry if it is just some typoe,
but I stared at it for quite some time and didn't find the bug ;->

(I found that by providing an overloaded exception class, and "use base"
die'ing after require because it couldn't match the "Can't locate ..."
error).

*ah* overload is great, once you realize it is there ;->

Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.0:

Configured by root at Fri Mar 24 17:33:21 CET 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.2, archname=i686-linux
    uname='linux cerebro 2.2.14 #59 smp fri mar 10 22:52:46 cet 2000 i686 unknown '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=undef 
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
    cc='gcc', optimize='-Os -mpentiumpro -g', gccversion=pgcc-2.95.2 19991024 (release)
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccflags ='-fno-strict-aliasing -I/usr/local/include'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
    alignbytes=4, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-ldl -lm -lc -lcrypt
    libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.0:
    /usr/app/lib/perl5
    /usr/app/lib/perl5
    /usr/app/lib/perl5
    /usr/app/lib/perl5
    .


Environment for perl v5.6.0:
    HOME=/root
    LANG (unset)
    LANGUAGE (unset)
    LC_CTYPE=de
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=:/usr/app/FM556_linux/bin:/root/cc/dejagnu/bin:/usr/app/qt/bin/:.:/root/s:/bin:/sbin:/usr/bin:/usr/sbin:/usr/app/bin:/usr/app/sbin:/usr/X11/bin:/usr/games:/usr/maple/bin:/usr/kde/bin:/usr/gnome/bin:/home/pg/bin:/opt/jdk118/bin:/opt/bin:/localvol/usr/app/insure++/bin.linux
    PERLDB_OPTS=ornaments=0
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @gsar

On Sat, 17 Jun 2000 23​:21​:19 +0200, Marc Lehmann wrote​:

use overload '""' => sub { "Can" };

$x = bless {};

print "\$x is '$x'\n";
print "\$x does not start with 'Can'\n" if $x !~ /^Can/;
print "\$x is still '$x'\n";

Try perl-current, I believe there's a patch in there to fix it.
(perlhack.pod will tell you how to get perl-current, in case you didn't
know.)

Sarathy
gsar@​ActiveState.com

From [Unknown Contact. See original ticket]

On Sat, Jun 17, 2000 at 02​:39​:02PM -0700, Gurusamy Sarathy <gsar@​ActiveState.com> wrote​:

use overload '""' => sub { "Can" };
$x = bless {};
print "\$x does not start with 'Can'\n" if $x !~ /^Can/;

Try perl-current, I believe there's a patch in there to fix it.

Confirmed​: seems fixed in perl-current!! Great work, thanks a lot for your
efforts!

However "make test" still shows an (unrelated) error I reported earlier​:

io/nargv.............ok
io/open..............ok
io/openpid...........make​: *** [test] Error 129
Hangup
[Exit 129 (SIGHUP)]

...that was supposed to be fixed in perl-current (or so I was told).
(the newest file in my perl-current seems to be from Jun 8), so I assume
something different has been fixed.

(perlhack.pod will tell you how to get perl-current, in case you didn't
know.)

I'll always check against that version, in case I ever find a bug in perl
again ;)

From @gsar

On Sun, 18 Jun 2000 00​:30​:09 +0200, Marc Lehmann wrote​:

Confirmed​: seems fixed in perl-current!! Great work, thanks a lot for your
efforts!

Thank Ilya, not me.

However "make test" still shows an (unrelated) error I reported earlier​:

io/nargv.............ok
io/open..............ok
io/openpid...........make​: *** [test] Error 129
Hangup
[Exit 129 (SIGHUP)]

...that was supposed to be fixed in perl-current (or so I was told).

I don't recall ever encountering that problem, much less checking in
a patch to fix it. Can you run the test by hand and see exactly where
it fails and why?

Sarathy
gsar@​ActiveState.com

From [Unknown Contact. See original ticket]

On Sat, Jun 17, 2000 at 03​:49​:59PM -0700, Gurusamy Sarathy <gsar@​activestate.com> wrote​:

Confirmed​: seems fixed in perl-current!! Great work, thanks a lot for your
efforts!

Thank Ilya, not me.

Thanks to every perl contributor, and especially the hard working ones on
p5p ;->

io/openpid...........make​: *** [test] Error 129
Hangup
[Exit 129 (SIGHUP)]
...that was supposed to be fixed in perl-current (or so I was told).

I don't recall ever encountering that problem, much less checking in
a patch to fix it.

It was back in the 5.005_6x days when I sent in a bug report (without
doing firther tests). Anyway, here are some experiments...

When I add print "kill $killsig, $pidxx\n" before the two calls to kill in
that file, it prints something sane (e.g.

kill HUP, 31979

), but an strace shows that perl actually kills pid = 0​:

ok 5
kill HUP, 32073
[pid 32072] kill(0, SIGHUP <unfinished ...>

I can reliably reproduce it on all my machines (which includes a standard
slackware 7.0 gnu/linux system, so my initial suspects - pgcc and/or my
self-compiled glibc - are not the culprits).

If this definitely doesn't ring a bell on where the problem could be I
could try to dig farther into the matter.