RE: [avr-libc-dev] Re: [avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib...

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Dmitry K.
> Sent: Wednesday, December 19, 2007 6:38 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] Re: 
> [avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib...
> 
> On Thursday 20 December 2007 00:53, Weddington, Eric wrote:
> > > Because that bug is completely unimportant and purely cosmetical.
> > > Real embedded applications don't exit() anyway.  Mind you, we (at
> > > least you and me) have been shipping compiler/library combinations
> > > where returning from main() didn't jump to or call exit() 
> at all, and
> > > people barely noticed it.
> [...]
> 
> I agree that bug is unimportant and cosmetical. For me it
> is no significance is CLI in abort/exit Avr-libc's functions,
> or is not.
> 
> But I have a few rationales against to keep GCC busy with CLI:
> 

I believe that there is enough rationale that it is worth doing the
change. In discussion with other colleagues, having a default interrupt
handler go to abort, and eventually an infinite loop with interrupts
disabled is a worthwhile method for detecting this application bug.

I think the question is now *where* to do the fix (avr-libc, gcc, which
function), and *when* to do the fix (now, or later [gcc 4.3.0, avr-libc
1.8.0]). Considering that I'm in desparate need to get a WinAVR release
out now, I would rather put this off to later.

But I definitely don't want to forget about this issue. I think that
this is an important enough change. Dmitry, would you be willing to add
a Task to the Task Tracker on avr-libc for this?

Thanks,
Eric