Filter::Simple error messages getting mangled inside require

[p5pRT]

Migrated from rt.perl.org#38920 (status was 'resolved')

Searchable as RT38920$

[p5pRT]

From @nwc10

Created by @nwc10

Not sure if this is a Filter​::Simple bug, or a more general core bug.
Given my module​:

package Shout;

use Filter​::Simple;

FILTER_ONLY (string => sub { $_ =~ tr/a-z/A-Z/; });

1;
__END__

then if I try to feed a perl script through it that it converts to erroneous
perl, I see a sensible error message​:

$ cat filter.pl
use Shout;

print "Oi!\n";
__END__
$ perl filter.pl
Missing braces on \N{} at filter.pl line 3, within string
Execution of filter.pl aborted due to compilation errors.

which is what I expect.

However, if that same code is in a module​:

$ cat Filter.pm
use Shout;

print "Oi!\n";

1;
___END__
$ perl -e 'use Filter'
No quotelike operator found after prefix at ";
...", detected at offset 18Missing braces on \N{} at Filter.pm line 3, within string
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

It all gets mangled. The mangling seems wrong.
IIRC Robin and I found something similar while looking at Switch.pm, while
he was starting out on his switch patch. Something to do with calling die
a second time, and therefore it rethrows $@​. But I'm not certain of this.

Nicholas Clark

Perl Info

Flags:
    category=library
    severity=low

Site configuration information for perl 5.9.4:

Configured by nick at Fri Apr 14 17:24:09 BST 2006.

Summary of my perl5 (revision 5 version 9 subversion 4) configuration:
  Platform:
    osname=freebsd, osvers=5.3-release-p28, archname=i386-freebsd-thread-multi
    uname='freebsd saigo.etla.org 5.3-release-p28 freebsd 5.3-release-p28 #0: wed mar 29 21:59:21 bst 2006 root@saigo.etla.org:usrobjusrsrcsyssaigo i386 '
    config_args='-Dusedevel=y -Dcc=ccache gcc -Dld=gcc -Ubincompat5005 -Uinstallusrbinperl -Dcf_email=nick@ccl4.org -Dperladmin=nick@ccl4.org -Dinc_version_list=  -Dinc_version_list_init=0 -Doptimize=-g -Dusethreads -Uuse64bitint -Uusemymalloc -Duseperlio -Dprefix=~/Sandpit/snap5.9.x-27802 -Dinstallman1dir=none -Dinstallman3dir=none -de'
    hint=recommended, useposix=true, d_sigaction=define
    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='ccache gcc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include',
    optimize='-g',
    cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include'
    ccversion='', gccversion='3.4.2 [FreeBSD] 20040728', 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 ='-Wl,-E  -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib
    libs=-lm -lcrypt -lutil -lc_r
    perllibs=-lm -lcrypt -lutil -lc_r
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-DPIC -fPIC', lddlflags='-shared  -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.9.4:
    lib
    /home/nick/Sandpit/snap5.9.x-27802/lib/perl5/5.9.4/i386-freebsd-thread-multi
    /home/nick/Sandpit/snap5.9.x-27802/lib/perl5/5.9.4
    /home/nick/Sandpit/snap5.9.x-27802/lib/perl5/site_perl/5.9.4/i386-freebsd-thread-multi
    /home/nick/Sandpit/snap5.9.x-27802/lib/perl5/site_perl/5.9.4
    .


Environment for perl 5.9.4:
    HOME=/home/nick
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/nick/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/nick/bin:/usr/local/sbin:/sbin:/usr/sbin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/bash

[p5pRT]

From @cpansprout

On Fri Apr 14 12​:53​:25 2006, nicholas wrote​:

Not sure if this is a Filter​::Simple bug, or a more general core bug.
Given my module​:

package Shout;

use Filter​::Simple;

FILTER_ONLY (string => sub { $_ =~ tr/a-z/A-Z/; });

1;
__END__

then if I try to feed a perl script through it that it converts to
erroneous
perl, I see a sensible error message​:

$ cat filter.pl
use Shout;

print "Oi!\n";
__END__
$ perl filter.pl
Missing braces on \N{} at filter.pl line 3, within string
Execution of filter.pl aborted due to compilation errors.

which is what I expect.

However, if that same code is in a module​:

$ cat Filter.pm
use Shout;

print "Oi!\n";

1;
___END__
$ perl -e 'use Filter'
No quotelike operator found after prefix at ";
...", detected at offset 18Missing braces on \N{} at Filter.pm line 3,
within string
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

It all gets mangled. The mangling seems wrong.

Replace that \n in Filter.pm with \N and change Shout.pm to

#__BEGIN__
package Shout;

use Filter​::Util​::Call;

sub import {
filter_add sub { my $status = filter_read; $@​="aaaaa"; $status }
}
1;
__END__

And you get this​:

aaaaaCompilation failed in require.
BEGIN failed--compilation aborted.

On encountering syntax errors, perl appends the messages to $@​, but the
filter keeps running. So the filter can clobber $@​, causing the
‘Compilation failed in require’ message to be appended to the modified $@​.
It seems far too easy for filters to make that mistake, so $@​ should be
localised. But should the core do it, or should Filter​::Util​::Call do it?

[p5pRT]

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

[p5pRT]

From zefram@fysh.org

Father Chrysostomos wrote​:

It seems far too easy for filters to make that mistake, so $@​ should be
localised. But should the core do it, or should Filter​::Util​::Call do it?

The core should localise it, to match the treatment of BEGIN blocks.
Fixed in commit b6f3718.

It's tricky to test. Filter​::Util​::Call is a cpan/ distro with its own
tests, and there's not much access otherwise to filtering from pure Perl.
But I found that hook subroutines in @​INC are also affected by this
problem, though differently, so I put in a test that uses that mechanism.

-zefram

[p5pRT]

@cpansprout - Status changed from 'open' to 'pending release'

[p5pRT]

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

[p5pRT]

@khwilliamson - Status changed from 'pending release' to 'resolved'