In article <[EMAIL PROTECTED]>,
Rafael Garcia-Suarez <[EMAIL PROTECTED]> writes:
> Ok, select($$$$) now returns undef on error as of change #24223.
/me raises the backward compatibility police card
For what it's worth, I think this is a bad idea.
First of all it basically breaks the error handling in all my
select() code where I typically do something like:
if (select(..) >= 0) {
play a bit with time and handles, i don't really care what the exact
number that got returned is
} elsif ($! == EINTR) {
redo some loop;
} else {
die "Unexpectedd select failure: $!"
}
So now I'll get pointless undef warnings in the failure case and will never
get to the die even if I want it to.
So it DOES break existing code.
And fixing it so it works on *both* versions of perl gets messy too.
The systemcalls where you want failure to be undef are the ones you use
in a boolean context, and it doesn't make much sense to me to put "0"
in the false (something failed/something special happened) group.
0 isn't that special a returncode for select(), It remains "the number of
handles in the masks". I'm not even sure from the select manpages it's
guaranteed to be zero in case of timeout. All my manpage says is it *can*
be zero in that case, so I'm uncertain that checking for 0 to determine
timeout is even valid. And after a select returning you normally have to
determine the current time and re-determine the time to next timeout for
the next select() anyways, so you'll also need to check if that interval
has gone negative (which is why in my code I never bother to really look at
the select returncode, except to see that it isn't -1).
If you wanted it to behave like the "boolean" systemcalls, you'd need to
make 0 into "0 but true". THAT would be consistent, but I bet that would
break lots of code.
Also notice that there are other calls in perl that do the -1 on failure,
see tell(), waitpid(), wait(), syscall(). So it isn't as if it happens
nowhere else in perl.
