On Sun, Jul 25, 2021 at 05:21:19PM -0600, Theo de Raadt wrote: > Scott Cheloha <[email protected]> wrote: > > > On Sun, Jul 25, 2021 at 01:35:19PM -0600, Theo de Raadt wrote: > > > This is a lot of fuss. > > > > > > How many bugs have you found relating to this issue? > > > > > > Let me guess: zero? > > > > Right, that's why I'm asking if we need to make a portability > > recommendation at all. > > > > We could also say something like: > > > > The standard permits sleep() implementations based on > > alarm(3). This implementation does not use alarm(3). > > > > ... or we could say nothing about SIGALRM. I don't know. > > Have you found any impacted implimentations? No.
Can't find any current implementations. Older implementations, yes. > Why bother documenting a gotcha which noone has ever made? Not never. SIGALRM-based sleep() was commonplace until the end of the 90s and it's still permitted by the standard. OpenBSD had a SIGALRM-based sleep(3) up until 1997: http://cvsweb.openbsd.org/src/lib/libc/gen/sleep.c?rev=1.6&content-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/src/lib/libc/gen/sleep.c?rev=1.7&content-type=text/x-cvsweb-markup Given this, I want to tell the reader, roughly: "hey! it's plausible there is a SIGALRM-based sleep() implementation using still floating around out there in the wild. If you find one, you'll want to avoid using it because there are unfixable bugs in such an implementation. Maybe use nanosleep() instead. If you *do* use it, just know that it will behave differently from OpenBSD's sleep() in some corner cases." But if you really think there is no point in mentioning that, and others agree with you, then we won't mention it.
