avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry K.
Subject: Re: [avr-libc-dev] Re: [avr-libc-commit] avr-libcChangeLoginclude/stdlib.h libc/stdlib...
Date: Thu, 20 Dec 2007 11:38:15 +1000
User-agent: KMail/1.5

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:

. Yes, the abort() function associates with a rough stop of
work.  But it is not obvious in case of a normal return from
main().  Why and to not finish, for example, transfer of the
buffer on RS-232 by interruptions? (I shall specify, that it
is onle an idea about natural behaviour.)

. The user at an input of main() has received control with
the forbidden interruptions and has enabled them himself.
Means, it is his duty to restore the I-flag at the return,
if it is needed to him.  Roughly, we do not demand from the
compiler to extinguish all LEDs not extinguished by us!

. Reduction of accessible memory even on one word on small
MCUs is completely not indifferent.

Dmitry.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]