[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] RFC: deprecate INTERRUPT, and replace it by something
Re: [avr-libc-dev] RFC: deprecate INTERRUPT, and replace it by something less ambiguous
Thu, 10 Feb 2005 06:01:36 -0700
Mozilla Thunderbird 1.0 (Windows/20041206)
Joerg Wunsch wrote:
Part of the issue, is that these names are derived from the GCC
*attributes* for these functions.
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.
Suggestions about the new name? Maybe SIGNAL_SEI?
#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