%% "Michael Sterrett -Mr. Bones.-" <[EMAIL PROTECTED]> writes:
ms> Do the specifications say that EINTR is not required or that it
ms> is forbidden?
Hmm. They say that a function may have more return error codes than
listed in the standards, so you're right: I guess there's nothing
technically preventing EINTR.
stat() is listed as required to be safe to call within a signal handler,
which isn't directly related of course.
ms> EINTR A signal was caught during the stat() or
ms> lstat() function.
ms> Without the code, there's no way for me to know if Solaris will
ms> actually ever fail with EINTR, but the man pages seems to indicate
ms> that it *could*.
I suspect, but can't prove, that you won't get EINTR from stat(2) for
"normal" filesystems.
ms> I guess I'm still not convinced that this problem couldn't be
ms> reproduced if sufficiently adverse conditions were
ms> encountered, even on "normal" UNIX systems. I'm for adding
ms> the loop on EINTR to the GNU make code base.
I just find it hard to believe that there have been no other reported
cases of this anywhere else; if it's possible, no matter how obscure, it
seems like _someone_ else would have hit it somewhere, by now. Sigh.
The problem is, there are a number of places that use stat(2) in GNU
make in addition to this one. Do we need to armor them all? What about
other system calls?
If this is a real (even potential) problem for most/all OS's, then maybe
a different solution than wrapping all the system calls in EINTR checks
is in order.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.ultranet.com/~pauld/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
