RE: [avr-libc-dev] What about to make 'reti' as a default behaviour?

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Dmitry K.
> Sent: Monday, December 17, 2007 3:57 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a 
> default behaviour?
> 
> > > Not always safe - if interrupt is level triggered, and remains
> > > active, the main program will be interrupted again and again...
> > > This will make the main program run much slower (interrupt and
> > > "reti" after every instruction), but work fine otherwise - so
> > > it may be difficult to notice the bug (no handler defined for an
> > > enabled interrupt).
> 
> Marek, thanks for the weighty remark.
> 
> Nevertheless, I tend to a variant with returning. Why?
> In practice more often the mistake happens such: "no handler
> defined for an enabled interrupt". The situation when the user
> initiated interruptions which actually it in any way did not
> plan to use is improbable. (At least, by the moment of end
> of the project). Really, it can not notice delay of the
> program, but hardly incomplete functionality of system will be
> covered from its look. On the other hand, in this case the user
> can localize at once malfunction (a debugging output, LED...).
> While in a variant with cycling the user can say only:
> "My controller has died."

Before we go too much further in this discussion, I would like to
propose that this feature not be included in 1.6.0 as it is about to be
released. I would prefer that if anything comes from this, that it goes
in 1.6.1.

Regarding the discussion: First, is it an error to not have a handler
for an enabled interrupt? I would think yes.
Is there anyway for a tool to detect (via static analysis) that a
handler does not exist for an enabled interrupt? It would not be
impossible, but extremely difficult to do.
So, what can avr-libc provide, as a default, that would let the user
know at run-time that a handler does not exist for an enabled interrupt?
If the default is just to return, then I would agree that that does not
really let the user know of the error. It can get too easily lost. The
symptoms would just be reduced performance.
The current default, jump to zero, seems inadequate because of known
issues with doing this.
Marek's idea of going to an infinite loop seems reasonable because it
would be easily detectable by the user in almost any embedded system.
Would it be better to have the default call exit(1)? Does the default
implementation of exit go into an infinite loop?

Thanks,
Eric W.