Sam Hartman <[EMAIL PROTECTED]> writes: > This problem certainly is real and is happening to other people as > well. When I looked at it, I convinced myself that errno of EINTR > was just an artifact--just what was currently sitting in erno and > that the read call was failing with EOF not with an error.
I thought read() returned zero on EOF and only returned -1 on a real error. Does the code in question not distinguish between these outcomes? This may be an argument for setting "errno = 0" just before the read(). Also, this sort of "faulty errno" problem can be caused by signal handlers which do not preserve errno. Any signal handler which makes system calls should preserve errno. Failing to do so can create particularly pernicious bugs, because basically all code (including the C library) referencing errno assumes is not going to be modified asynchronously. Bash 1.x actually had a bug of this sort in its SIGCHLD handler which generated an "impossible" ECHILD return from a read() call. - Pat _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
