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

[Joerg Wunsch]

As Dmitry K. wrote:

> . 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.)

Well, normal applications wouldn't call exit() anyway.  If they do, I
think something like an atexit()-Handler would be the more natural way
of performing cleanup tasks.  Yes, I think of eventually implementing
atexit(), albeit it's more of a "checkbox item", just to be as close
to the C standard as possible.  I don't expect many people to ever use
that feature. ;-)

One concern with leaving interrupts enabled is that upon calling
exit(), anyone would most likely expect the application to stop, about
in the same way as it would under control of an operating system.  Now
have a look e.g. at the "simple demo" from avr-libc, and think what
would happen if you suddenly returned from main() there?  Nothing, the
application would continue to work as before (except it wouldn't sleep
the CPU anymore), because all the work is done inside the interrupt
handler.

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

That's why I'd like to have the CLI in _exit rather than both, in
abort and exit.  If anyone is concerned about the few bytes of memory
consumed by exit()/_exit(), and he's also reasonably sure he will
never call exit() anyway, they could use --defsym=exit=0 on the linker
command line.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)