However, it's critical that $! be "emptied" (set to a FALSE value) before calling readline, if $! is to be used to distinguish between EOF and a read error, as the code from perldoc readline does.

However, it's critical that $! be "emptied"

It's not critical at all - I've already mentioned that undefining $! is a useless, almost redundant operation, consequetive operations will clear and set a previously set $! if they need to.

As in the following example, "gobbledegook" is a non-existant file.


$ perl -le 'open F, "gobbledegook" or print "WARN1: $!"; print "PRINT:
+ $!"; readlink "test" or print "WARN2: $!";  print "PRINT: $!'
WARN1: No such file or directory
PRINT: No such file or directory
WARN2: Invalid argument
PRINT: Invalid argument
[download]

It's quite clear here that the currency or validity of $! after a system call is unaffected by it's previous state, it's just another global variable.

I have reason to believe that some perl programmers undefine $! after a system call wherein they do not check or cannot check the return value or because $! wasn't localized during that operation. E.g. After a use; statement


$ perl -e 'print "BANG: $!"'
BANG:

$ perl -Mstrict -e 'print "BANG: $!"'
BANG: Bad file descriptor
[download]

You're wrong about the use of $!, at least on unix. The errno variable is not cleared by successful system calls, but it is set by failing ones. In order to distinguish successful and failing system calls by the use of errno alone, it is necessary to clear errno before making the system call. Here's the relevant part of the readline documentation:

... until end-of-file is reached, whereupon the subsequent call returns undef.
If readline encounters an operating system error, $! will be set with the corresponding error message. It can be helpful to check $! when you are reading from filehandles you don't trust, such as a tty or a socket. The following example uses the operator form of readline, and takes the necessary steps to ensure that readline was successful.

for (;;) {
  undef $!;
  unless (defined( $line = <> )) {
    die $! if $!;
    last; # reached EOF
  }
  # ...
}
[download]

Based on the documentation, readline returns undef in two cases: EOF or I/O error. In the case of EOF, $! (or errno) is not modified and will have the value it had before readline was called, since the system call(s) have not failed. In the case of an I/O error, $! will have the corresponding errno value which resulted from the failing system call. In order to distinguish them, $! must be cleared before calling readline. If $! were not cleared, then after a call to readline which reached EOF, it would still have the same value it had before the call. If that value happened to be non-zero (which your examples show can easily happen), then it would appear that readline returned undef because an I/O error occurred.

Here is some code which demonstrates that $! retains its value from before the readline call when EOF is reached and that therefore it is essential to clear $! in order to distinguish an I/O error from EOF.

#!/usr/bin/perl 
sub doit {
   open FH, shift or die "open failure: $!\n";
   $! = shift;
   1 while <FH>;
   $n = $!+0;
   print "n=$n s=$!\n";
}
doit $0, 5;   
doit $0, 6;  
doit $0, undef;
[download]

produces:

n=5 s=I/O error
n=6 s=No such device or address
n=0 s=
[download]