in reply to Re^3: "use strict" sets $!
in thread "use strict" sets $!

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 $!"
$! 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 $!"
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 $!"
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>

Replies are listed 'Best First'.
Re^5: "use strict" sets $!
by ig (Vicar) on Aug 19, 2009 at 13:08 UTC
    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.