typdef'ing from sig_atomic_t valid?

[Kevin D. Quitt]

The point is that you don't know what is the type that can be atomically
written to, even if it exists. On the Cray it is int, on an 8-bit micro
it is char. Hence the need for sig_atomic_t.

OK. It's strictly for portability. I have to revise my view of it, then;
it does have a real (meta) use.

You're forgetting that clearing the sig_atomic_t flag is an atomic
operation *by definition*, therefore your scenario cannot happen.

Nah - the client read the value into another variable, or uses the
variable in a switch or if. It's another line of code before it can get
around to setting it to zero. The interrupt can happen in between, so you
can still lose the information.

Bullshit!

Except for portability, I stand by the comment. If you use a volatile
variable that's the right size for the hardware in question, adding
sig_atomic_t to it gets you no more protection.

You're the only who failed to really engage his brain on this issue,
despite the detailed explanations you have already gotten.

Apparently so. Your immediately previous post is the only one that
specifically said it was to guarantee portability. I guess I was still
thinking down in the hardware details and not an abstract enough.

You're behaving like an idiot in this thread.

I was behaving ignorantly in this thread, trying to cure my ignorance.
With your (and others') help, I've cured it. I thank you.

 

[Dan Pop]

OK. It's strictly for portability. I have to revise my view of it, then;
it does have a real (meta) use.

Try to write a portable signal handler, according to the standard
specification, and you'll see that there is no place for "meta"
in your statement above.

Nah - the client read the value into another variable, or uses the
variable in a switch or if. It's another line of code before it can get
around to setting it to zero. The interrupt can happen in between, so you
can still lose the information.

If you want to shoot yourself in the foot, C is not going to prevent you
from doing it. The point is that sig_atomic_t *can* be safely used in
portable C code. Look again at the demo code I've posted. There is no
danger to lose any information there.

There is one genuine problem with signal handling in standard C and it
was recently discussed in comp.std.c, so I'm not going to rehash it here
(the standard specification allows race conditions).

Except for portability, I stand by the comment.

The only reason to pay any attention to the C standard is portability.
Otherwise, the documentation of your compiler is much better and provides
lots of extra functionality. So, I miss your point: *everything* in the
C standard is about portability and sig_atomic_t is no exception.

Dan