Re: [avr-libc-dev] RFC: deprecate INTERRUPT, and replace it by something less ambiguous

[E. Weddington]

Joerg Wunsch wrote:

> As many users seem to run into constant confusion about the use of
> INTERRUPT, and tend to use it when they are rather supposed to use
> SIGNAL instead (either because they didn't read the documentation, or
> because they didn't notice the difference when reading it), I propose
> that we deprecate INTERRUPT, and rename it to something that is less
> probable of causing confusion.
>
> If we deprecate it now, the next major stable release line (1.4.x)
> could already remove it.  There are probably only very few legitimate
> users of INTERRUPT, so requesting them to change their code upon the
> next major release doesn't appear undue to me.
>
> Opinions?
>
> Suggestions about the new name?  Maybe SIGNAL_SEI?
>
>  
Part of the issue, is that these names are derived from the GCC 
*attributes* for these functions.
In <avr/signal.h>:

#define SIGNAL(signame)                    \
void signame (void) __attribute__ ((signal));        \
void signame (void)

#define INTERRUPT(signame)                \
void signame (void) __attribute__ ((interrupt));    \
void signame (void)

So, should this be changed in GCC too?

I would also ask, is it worth it to rename it? Why not do away with 
__attribute__((interrupt)) all together?
Or more technically, why not do away with __attribute__((interrupt)), 
and then change the name of __attribute__((signal)) to 
__attribute__((interrupt)) but keep the same semantics?

I would postulate that hardly anyone really uses ISRs that can be 
interrupted; it's too easy to do it wrong and cause stack overflows. And 
if somebody really needs to do it, they can always throw in an sei() at 
the beginning of the ISR.


With this RFC, I would like to also propose combining <avr/signal.h> and 
<avr/interrupt.h>. Everything to do with interrupts, declaring them, 
turning them on or off, under one header, with it being perhaps 
<avr/interrupt.h>.

Eric