When is line 1 not line 1?

When eval-ing a simple use without a final semicolon, and doubly so on Solaris.

Sometimes eval 'some deadly code' dies at line 2 instead of line 1.

Here's a simple module that Carps on import:

package FooCarp;
use Carp ();
sub import { Carp::carp "I'm a fish" }
1;

Here's a test:

# fish.pl
eval 'use FooCarp';
print $@;
eval 'use FooCarp qw(woot)';
print $@;
eval 'use FooCarp;';
print $@;
eval 'use FooCarp qw(woot);';
print $@;

Linux:

I'm a fish at (eval 1) line 2.
I'm a fish at (eval 2) line 1.
I'm a fish at (eval 3) line 1.
I'm a fish at (eval 4) line 1.

Ok, the first one is a bit weird. eval a failing use without an argument nor a semicolon and you end up on line 2. This may be related to the ancient "Erroneous line numbers reported with '#line' in 'eval'" bug report [perl #7600] which seems to be fixed in the simple case in the report.

But the same on Solaris:

I'm a fish at (eval 1) line 2.
I'm a fish at (eval 2) line 2.   <-- wut?
I'm a fish at (eval 3) line 1.
I'm a fish at (eval 4) line 1.

Gives different results. This makes me scratch my head and grumble (and it causes a test in Contextual::Return to fail.

I would have thought it was my build of Perl, but since DCONWAY hasn't gotten tons of test failure reports for C::R it's not a common Linux/OSX issue. And I've tested on every version of Perl on my systems going back to 5.6.1 and buit by various other people with a mix of GCC and Sun's CC, and my Perls up to current blead... It's somehow Solaris that's broken. I have no idea why.

Does anybody have any hints where to go digging for a fix?

1 Comment

This is a feature for detecting whether or not you're running on Solaris. ($^O is not read-only, so cannot be trusted.)

;-)

Leave a comment

About zengargoyle

user-pic