When SIGINT is delivered for the first time, shouldn't the handler code be executed and its action default to SIG_DFL of SIGINT so that the next time when SIGINT is delivered it should logically terminate
Its not happening so,
each time a SIGINT is delivered, handler is executing without any problems.
Resetting the handler is dumb. That is the original behavior, but during the window between the automatic reset and the reinstallation of the handler, a signal can be lost. So BSD changed signal(). On HP-UX, you can get either behavior by linking with different libraries. Anyway, both behaviors were in use when Posix came along. So, according to the Posix standard:
I perfectly agree with the above and have been using that only.
Am just curious to know about the behavior of signal(); and why its behavior is different in different systems.
Is it due to the reason that different libraries are in use ? If so, how to identify them ?
Am confused about this too, there is no guarantee with the older semantics that the signal of same type will not be delivered while the current function block for the signal is being executed.
In that case, there is no reason for it to wait till the function block is executed.
In short, can it be said signal() behavior is undefined - or am I being rude in saying that ?
"Undefined" is a little harsh. It's not like signal() is allowed to whistle dixie or anything. I would use the term "unpredictable". A standard signal() has several attributes each of which must be one of two possible behaviors. I thought that I explained "why":