Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tieing $SIG{__WARN__} is inconsistent #7445

Open
p5pRT opened this issue Aug 2, 2004 · 7 comments
Open

tieing $SIG{__WARN__} is inconsistent #7445

p5pRT opened this issue Aug 2, 2004 · 7 comments

Comments

@p5pRT
Copy link

p5pRT commented Aug 2, 2004

Migrated from rt.perl.org#30926 (status was 'open')

Searchable as RT30926$

@p5pRT
Copy link
Author

p5pRT commented Aug 2, 2004

From fergal@esatclear.ie

Created by fergal@esatclear.ie

Tested with 5.8.3 and 5.8.5.

It seems that perl has to see you putting a code ref into $SIG{__WARN__}
before it will pay any attention to $SIG{__WARN__}, so tieing doesn't work
until you assign a value. Once a value has been assigned, tieing works fine.

#! /usr/bin/perl

tie $SIG{__WARN__}, "Ignore", sub {
  warn "you should see this twice\n"
};
print "\$SIG{__WARN__} seems to have a coderef​: $SIG{__WARN__}\n";

warn "you should not see this but you will";
$SIG{__WARN__} = sub { warn "this will be ignored by ignored by the tie" };
warn "you will not see this and that's ok";

package Ignore;

sub TIESCALAR
{
  my $pkg = shift;
  my $value = shift;
  return bless \$value, $pkg;
}

sub FETCH
{
  return ${$_[0]};
}

sub STORE {}

The same applies to $SIG{__DIE__}.

perl should treat tieing just like assignment in terms of switching on and
off the $SIG handlers

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.3:

Configured by bhcompile at Thu Apr 15 13:08:28 EDT 2004.

Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
  Platform:
    osname=linux, osvers=2.4.21-4.elsmp, archname=i386-linux-thread-multi
    uname='linux tweety.devel.redhat.com 2.4.21-4.elsmp #1 smp fri oct 3 17:52:56 edt 2003 i686 i686 i386 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dversion=5.8.3 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.2 5.8.1 5.8.0'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2 -g -pipe -march=i386 -mcpu=i686',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='3.3.3 20040412 (Red Hat Linux 3.3.3-7)', 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', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.3.3.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.3.3'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.3:
    /home/fergal/my/src/lib//5.8.3/i386-linux-thread-multi
    /home/fergal/my/src/lib//5.8.3
    /home/fergal/my/src/lib//i386-linux-thread-multi
    /home/fergal/my/src/lib//5.8.2
    /home/fergal/my/src/lib//5.8.1
    /home/fergal/my/src/lib//5.8.0
    /home/fergal/my/src/lib/
    /usr/lib/perl5/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/5.8.3
    /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.3
    /usr/lib/perl5/site_perl/5.8.2
    /usr/lib/perl5/site_perl/5.8.1
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.3
    /usr/lib/perl5/vendor_perl/5.8.2
    /usr/lib/perl5/vendor_perl/5.8.1
    /usr/lib/perl5/vendor_perl/5.8.0
    /usr/lib/perl5/vendor_perl
    .


Environment for perl v5.8.3:
    HOME=/home/fergal
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/lib/j2sdk1.4.1_01/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/home/fergal/my/bin:/usr/games:/usr/local/lib/j2sdk1.4.1_01/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/home/fergal/my/bin:/usr/games:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/usr/X11R6/bin:/usr/X11R6/bin
    PERL5LIB=/home/fergal/my/src/lib/
    PERL_BADLANG (unset)
    SHELL=/bin/tcsh

@p5pRT
Copy link
Author

p5pRT commented Aug 5, 2004

From fergal@esatclear.ie

On Wed, Aug 04, 2004 at 07​:59​:24PM +0100, Nick Ing-Simmons wrote​:

The same applies to $SIG{__DIE__}.

perl should treat tieing just like assignment in terms of switching on and
off the $SIG handlers

Tie is normally used to defer actions until assign/test happens.
So perl is behaving exactly like I would expect.

What is the purpose of the tie?

I was trying to provide warn and die handlers which were as invisible and
bullet proof as possible, and would work well even for code with it's own
badly written warn/die handlers. I tied them to something that had a value
already and which always keeps that value, even after assignment. Any value
assigned to it would be stored away and could be accessed through the
object. So I'd do

my $obj = tie $SIG{__WARN__}, "Hide", \&my_handler;

sub my_handler {
  # do something interesting;
  goto &{$obj->hidden} if $obj->hidden;
}

so some bad code could come along and do

$SIG{__WARN__} = sub { blah };

and my handler would survive and call the new handler at the end. This
currently works, as long as you put a valid subref into $SIG{__WARN__}
before tieing. However if the bad code does

$SIG{__WARN__} = undef;

then my handler will not be called even though $SIG{__WARN__} still gives a
valid subref.

I presume there is an optimisation somewhere monitoring what appears to be
going into $SIG, switching it on and off but it doesn't take tie into
account.

I don't really have an appliction for this, I was writing a stack tracing
module and trying to make it as unintrusive as possible however
diagnostics.pm is now good enough for my purposes. I do think though that a
tied $SIG entry should either be illegal or should respect the value return
by FETCH regardless of what it saw being assigned,

F

@p5pRT
Copy link
Author

p5pRT commented Aug 5, 2004

From nick@ing-simmons.net

Fergal Daly <perl5-porters@​perl.org> writes​:

# New Ticket Created by Fergal Daly
# Please include the string​: [perl #30926]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org​:80/rt3/Ticket/Display.html?id=30926 >

This is a bug report for perl from fergal@​esatclear.ie,
generated with the help of perlbug 1.34 running under perl v5.8.3.

-----------------------------------------------------------------
[Please enter your report here]

Tested with 5.8.3 and 5.8.5.

It seems that perl has to see you putting a code ref into $SIG{__WARN__}
before it will pay any attention to $SIG{__WARN__}, so tieing doesn't work
until you assign a value. Once a value has been assigned, tieing works fine.

The same applies to $SIG{__DIE__}.

perl should treat tieing just like assignment in terms of switching on and
off the $SIG handlers

Tie is normally used to defer actions until assign/test happens.
So perl is behaving exactly like I would expect.

What is the purpose of the tie?

@p5pRT
Copy link
Author

p5pRT commented Aug 5, 2004

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

@p5pRT
Copy link
Author

p5pRT commented Aug 5, 2004

From nick@ing-simmons.net

Fergal Daly <fergal@​esatclear.ie> writes​:

On Wed, Aug 04, 2004 at 07​:59​:24PM +0100, Nick Ing-Simmons wrote​:

The same applies to $SIG{__DIE__}.

perl should treat tieing just like assignment in terms of switching on and
off the $SIG handlers

Tie is normally used to defer actions until assign/test happens.
So perl is behaving exactly like I would expect.

What is the purpose of the tie?

...

I don't really have an appliction for this, I was writing a stack tracing
module and trying to make it as unintrusive as possible however
diagnostics.pm is now good enough for my purposes. I do think though that a
tied $SIG entry should either be illegal or should respect the value return
by FETCH regardless of what it saw being assigned,

With that wording it does sound like a bug.
Can you create an example where FETCH value is ignored after a STORE?

F

@p5pRT
Copy link
Author

p5pRT commented Aug 5, 2004

From fergal@esatclear.ie

On Thu, Aug 05, 2004 at 08​:09​:20AM -0000, Nick Ing-Simmons via RT wrote​:

I don't really have an appliction for this, I was writing a stack tracing
module and trying to make it as unintrusive as possible however
diagnostics.pm is now good enough for my purposes. I do think though that a
tied $SIG entry should either be illegal or should respect the value return
by FETCH regardless of what it saw being assigned,

With that wording it does sound like a bug.
Can you create an example where FETCH value is ignored after a STORE?

This is the original example with an extra 3 lines to demonstrate what
happens when perl sees and undef being assigned,

F

#! /usr/bin/perl

tie $SIG{__WARN__}, "Ignore", sub {
  warn "you should see this twice\n"
};
print "\$SIG{__WARN__} seems to have a coderef​: $SIG{__WARN__}\n";

warn "you should not see this but you will";
$SIG{__WARN__} = sub { warn "this will be ignored by ignored by the tie" };
warn "you will not see this and that's ok";

################################
$SIG{__WARN__} = undef;
warn "you will see this and that's not ok";
warn "\$SIG{__WARN__} still seems to have a coderef​: $SIG{__WARN__}\n";
################################

package Ignore;

sub TIESCALAR
{
  my $pkg = shift;
  my $value = shift;
  return bless \$value, $pkg;
}

sub FETCH
{
  return ${$_[0]};
}

sub STORE {}

@p5pRT
Copy link
Author

p5pRT commented Oct 21, 2012

From @jkeenan

On Thu Aug 05 01​:54​:59 2004, fergal wrote​:

On Thu, Aug 05, 2004 at 08​:09​:20AM -0000, Nick Ing-Simmons via RT
wrote​:

I don't really have an appliction for this, I was writing a stack
tracing
module and trying to make it as unintrusive as possible however
diagnostics.pm is now good enough for my purposes. I do think
though that a
tied $SIG entry should either be illegal or should respect the
value return
by FETCH regardless of what it saw being assigned,

With that wording it does sound like a bug.
Can you create an example where FETCH value is ignored after a
STORE?

This is the original example with an extra 3 lines to demonstrate what
happens when perl sees and undef being assigned,

F

#! /usr/bin/perl

tie $SIG{__WARN__}, "Ignore", sub {
warn "you should see this twice\n"
};
print "\$SIG{__WARN__} seems to have a coderef​: $SIG{__WARN__}\n";

warn "you should not see this but you will";
$SIG{__WARN__} = sub { warn "this will be ignored by ignored by the
tie" };
warn "you will not see this and that's ok";

################################
$SIG{__WARN__} = undef;
warn "you will see this and that's not ok";
warn "\$SIG{__WARN__} still seems to have a coderef​:
$SIG{__WARN__}\n";
################################

package Ignore;

sub TIESCALAR
{
my $pkg = shift;
my $value = shift;
return bless \$value, $pkg;
}

sub FETCH
{
return ${$_[0]};
}

sub STORE {}

Discussion in this ticket petered out eight years ago, and Nick is no
longer around to continue it.

Is there anyone who could review the issues and make a recommendation?

Thank you very much.
Jim Keenan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants