Don't dump autodie from core (was Re: Coring Variable::Magic / autodiefights with string eval in Perl 5.10.x)

Front page | perl.perl5.porters | Postings from July 2009

Don't dump autodie from core (was Re: Coring Variable::Magic / autodiefights with string eval in Perl 5.10.x)

Thread Previous | Thread Next

From:

Paul Fenwick

Date:

July 5, 2009 06:47

Subject:

Don't dump autodie from core (was Re: Coring Variable::Magic / autodiefights with string eval in Perl 5.10.x)

Message ID:

4A50AECD.8040103@perltraining.com.au

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

G'day Dave / p5p,

Looks like I've opened an interesting discussion here, and I certainly
didn't expect it to move to "let's boot autodie from the core" territory.

I don't want to see autodie get pulled from the core, so let's for a moment
examine it as it currently stands: version 2.05.  We now have a known bug:
it can leak if used near string evals.

Firstly, it should be noted that this bug has existed since at least the
15th June 2008, so it's almost a year old.  During that time, none of
autodie's tests (of which there are more than 400) detected it.  Nobody
submitted a bug report.  Nobody came to me complaining of autodie leaking
scope.  Nobody's reported seeing this in the wild.   Instead, the bug came
to me because rafl had discovered it in other code, and advised me that
autodie may be affected.

So, the bug is rare, but that doesn't mean it isn't serious.  It is.
However it also has a workaround in its current form.  In fact, it has two
workarounds:

	1) Don't use string evals when autodie is in scope.
	2) Use an explicit "no autodie" to plug the leak.

A known bug with workarounds is much better than an unknown bug.  However
one can still argue that it's a big enough defect to pull autodie from core.
 But if we pull autodie from core, then what does that leave us with?

It leaves us with Fatal.  Fatal lacks the leaking bug, because by its very
nature it leaks everywhere.  It has package-wide scope.  There's no way to
restrict it to a single block, a single subroutine, or a single file.  Turn
it on, and it's on for your whole package.

And what does Fatal give you?  It gives you error messages that are famous
for their ugliness:

     $ perl -MFatal=open -e'open(my $fh, "<", "xyzzy");'
     Can't open(GLOB(0x1243928), <, xyzzy): No such file or directory at
    (eval 3) line 4
        main::__ANON__('GLOB(0x1243928)', '<', 'xyzzy') called at -e line 1

Oh yes, they're strings, too!  No exception objects here, if you want to
know what went wrong, you have to resort to regexpes and guessing.

What else does Fatal give us?  Oh yeah, I remember... bugs!  A big raft of
them.  Almost a dozen[1] of Perl's built-ins can legitimately return a false
value when successful, but Fatal can't handle that.  But it doesn't know
that, so it lets you wrap the built-in, but figuring out why that's not
working as you'd expect is left as an exercise for the developer.

In fact, for *everything* that Fatal does, autodie does it better.  I can
tear out the lexical handler for autodie, force users to install it with
package-wide scope, and it's still going to be better than Fatal in every way.

Throwing out autodie due to one bug that has never been seen in the wild is
like throwing out the baby with the bathwater.

I'm happy to document the bug and its workarounds, but I would ask you to
consider whether dropping autodie from 5.10.1 would actually improve Perl as
a whole.

Yours sincerely,

	Paul

[1] fork, recv, send, open, fileno, read, readlink, sysread, syswrite,
    sysseek and umask can all return false (zero) values on some successes.

- --
Paul Fenwick <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFKUK7Lx5N6j7FHnlURAmnaAJ9Oy9nnhf1f+QvOISO9jBmw+p8GYQCffjuT
M/obM3zhlFu/EzHzXlutYdE=
=gqSu
-----END PGP SIGNATURE-----

Thread Previous | Thread Next