Re: __attribute__((warn_unused_result)) for NetBSD?

On Sun, Sep 28, 2008 at 11:26:27PM -0400, der Mouse wrote:
 > > 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.)

Yes and no - despite the dire wording in the standards, the real issue
is that signals are essentially interrupts, so you might end up
reentering nonreentrant code. Because of the way signals are (and have
to be) implemented, making system calls is ~always going to be safe.
Calling libc functions like fopen, though, really is a bad idea.

However, that's a side issue.

 > But I see your point, and it's a good one.  Thank you for explaining.

*bow*

 > >>> 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.

Well, what's in POSIX is reasonably well specified but poorly chosen.
Because of this, the de facto real semantics exhibited by real
systems, which generally retain the historic behavior at least for
select(), are poorly specified.

-- 
David A. Holland
[email protected]