Is an interrupt a signal, according to the C spec?

Question

C11 5.1.2.3/5:

When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects that are neither lock-free atomic objects nor of type volatile sig_atomic_t are unspecified, as is the state of the floating-point environment. The value of any object modified by the handler that is neither a lock-free atomic object nor of type volatile sig_atomic_t becomes indeterminate when the handler exits, as does the state of the floating-point environment if it is modified by the handler and not restored to its original state.

This question is specifically about embedded systems, in a situation where there is no operating system-like setup.

On an embedded system classic signals (POSIX style) do not exist. Say we have an interrupt which calls multiple functions, all of whom work on the same ((semi-) global) variable, but this variable is not used from an out-of-interrupt context. Something like

static enum State state;

static void setStateTo1(void)
{
    state = stateOne;
}

static void setStateTo2(void)
{
    state = stateTwo;
}

void ISR(void)
{
    if (state == stateOne)
        setStateTo2();
    else
        setStateTo1();
}

Two questions:

1. Is an interrupt a signal?
2. Is the above code an example of undefined behaviour, because state is not volatile ?

Answer 1

The term "signal" refers to a specific thing whose behaviour is defined by the standard (C11 7.14 "Signal handling") ; that definition includes that the signal has a number, and can interrupt execution by jumping to a handler installed by the signal function, and so on.

The standard does not cover any other sort of asynchronous code execution besides signals and threads.

If your implementation offers any other sort of interrupt that doesn't follow the specification of signals, and the interrupt handler changes the behaviour of the abstract machine, then we could either say that the implementation is non-conforming, or that the code to install the signal handler causes undefined behaviour.

To be well-defined you can have the handlers do nothing besides writing volatile atomic variables.

So, your second question is beyond the scope of the Standard. In Standard C the optimizer could remove all of those functions as unused if they are never called by the program.

In reality an implementation that offers non-standard interrupts will be defining its own behaviour under its own purview, and you could consider it an extended dialect of C with that added functionality.

Answer 2

The authors of the Standard regarded many things as outside their jurisdiction . If an implementation were to use the stack in a way that would malfunction unpredictably if any interrupt occurred during program execution, and consequently required that the code it generates must only be run in situations where no interrupts could occur, such a limitation would not make the implementation non-conforming, though it would render it unsuitable for many purposes.

A quality implementation which is designed to be suitable for low-level programming on a particular platform should be expected to either extend the skeletal abstraction model given in the C Standard to include any parts of the platform's abstraction model that would be useful for that purpose, or else document a sound reason for doing otherwise, but Quality of Implementation issues are outside the Standard's jurisdiction. Whether a particular implementation should be expected to work usefully in cases beyond those contemplated by the Standard depends upon whether its designers were interested in making it suitable for a wide range of low-level programming tasks, or interested only suitability for purposes contemplated by the Standard.