Re: __attribute__((warn_unused_result)) for NetBSD?
der Mouse <[email protected]> Sun, 28 Sep 2008 23:26:27 -0400 (EDT)
| Newsgroups | gmane.os.netbsd.devel.general |
|---|---|
| Message-ID | <[email protected]> |
>>> Then POSIX stuck their oar in and decided [syscall restart] ought >>> to be an attribute of the signal; unfortunately, that doesn't work, >> Doesn't work? In what sense? (It looks reasonable to me; I'm >> wondering what I'm missing.) > Well, consider select(). If your program has a select loop, [...]. > Then suppose you want to catch some signal. (Common cases include > SIGCHLD if you also have subprocesses, or SIGHUP if you're a daemon > with config to reload.) Recall that a signal handler, being an > interrupt, is roughly speaking not allowed to do anything other than > assign a value of type sig_atomic_t. Not quite. Rather, if it does do any other thing, it is off in implementation-dependent weeds. (For example, I have a program which depends on close() working in a signal handler - by simply declaring that I don't care about portability to systems where that doesn't work the way the code expects.) But I see your point, and it's a good one. Thank you for explaining. >>> so now it's sort of both and the real semantics are poorly >>> specified. >> Well, yeah, if POSIX didn't bother specifying exactly what they >> meant, I can see that would be a problem. > No, they did (AFAICR); it's just wrong. Hm, that's not how I'd read "poorly specified". I'd phrase that as more "well specified but poorly chosen". But that's a semantic niggle; I agree with what you meant. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B