Re^2: Bareword "SEEK_END" not allowed while "strict subs" in use (FH)

[tye]

Using bareword symbols to refer to file handles is particularly evil because they are global, and you have no idea if that symbol already points to some other file handle. You can mitigate some of that risk by localizing the symbol first

It isn't particularly hard to grep for "FH" being used elsewhere in the current package. And local doesn't actually mitigate that risk much unless you only use the file handle for the duration of some short-lived subroutine (and there are no subroutines in the original code).

Oh, and it was 5.6.1 where "open my $fh" became supported. :)

[Monk::Thomas]

*Erm* It's not about your package. It suffices if some library (which you may not even call directly) is using FH to read/write a file. Suddenly your file descriptor points to some totally different file/is closed/open for writing instead of reading or something completely different.

I'm sure I don't have enough time to debug something like this. Do you?

[tye]

No. Test it if you don't believe me. FHs are global to the current package, just like all other non-"special" globals.

[Monk::Thomas]

Well. I did test. I even installed an ancient perl 5.8.8 to make sure it hasn't been patched somewhere in between. You are right, I am wrong. I bow my head in shame.

But although I was wrong I still recommend to use variables for filehandles because a namespace collision may happen even though one carefully grepped the source code.

---

There's another issue and I misremembered it. I deliberately do something obviously stupid here to provoke the error.

#!/usr/bin/perl

use strict;
use warnings;

open say, '<', '/etc/nsswitch.conf'
  or die "Unable to open file1: $!\n";

print "Filehandle is now open!\n";

print "1: " . <say>;

exit;

This results in:

Filehandle is now open!
1: # /etc/nsswitch.conf

You'll probably also get a warning: 'Unquoted string "say" may clash with future reserved word at <script> line 8.' - something fishy is going on here. In a simple script you're likely to notice it. In a web- or GUI-driven application you probably don't.

Let's upgrade our perl and add a single line

use 5.010;

And suddenly the previously 'well-behaving' application goes boom.

Name "main::say" used only once: possible typo at <script> line 13.
Use of uninitialized value $_ in say at <script> line 8.

Can't use string ("1") as a symbol ref while "strict refs" in use at <
+script> line 8.

What?!!

'use 5.10' exports 'say()' into your namespace. And suddenly open() does not open a filehandle 'say' but a function say(). Boom. Trying to debug that in a real world application may cause some serious headscratching - it's not that obvious anymore - especially if there's nobody warning you that library 'xyz' may accidently export your favourite filehandle name in the future.