I wondered what in "use strict" might have caused a failed system call

Maybe you know this also but your quest for a failed system call suggests that maybe you don't or that there might be some confusion...

The fact that $! is non-zero is not an indication that any system call failed. If you know that the last system call failed then the value of $! has meaning, otherwise its value doesn't mean anything at all.

otherwise its value doesn't mean anything at all.

Isn't "at all" too strong here? $! (i.e. errno is initially zero (as far I remember, this is guaranteed by the C standard), and gets a non-zero value if someone sets it - for instance, in a failed system call or if in Perl it is explicitly set by assignment. Seeing it only this way, the value of $! picked up somewhere in the middle of a program execution indeed doesn't mean much.

But here we have a different situation: We see that in the program

perl -lwe "print $!"
[download]

$! is zero, which means that when Perl starts executing a (correct) program, $! happens to be zero. We also see that for instance

perl -lwe "use warnings; print $!"
[download]

print zero, so just the fact that Perl has to compile a pragma, doesn't change the value of $!. But we see that

perl -lwe "use strict; print $!"
[download]

prints a non-zero value, and from this I conclude that $! must be set somewhere somehow within strict.pm. Being a curious person, I had a look at the source of strict.pm. I didn't find a direct assignment to $! (which is no surprise - we wouldn't expect this anyway), and the system calls I found (and which could possibly set $! to a 'bad file descriptor' error number), are in blocks belonging to error handling (i.e. I would have seen an error message, if such a branch would have taken). That's why I was puzzled and became curious. I admit that it is only for academic interest and has not much practical value aside of satisfying my curiosity ;-)
-- 
Ronald Fischer <ynnor@mm.st>

Isn't "at all" too strong here?

Perhaps a bit too strong. It depends where one chooses to find meaning. If one seeks meaning in the system interface specification then there is none. The specification is clear that a successful system call may change errno and may leave it with any value and defines no meaning for any value of errno after a successful system call. To this extent, the value of errno after a succesful system call has no meaning.

Yet, if errno is set by a successful system call there is some reason - it has something to do with the implementation of the system call. One can find meaning in the code of the system call. But any such meaning might be highly implementation specific.