avrdude-dev
[Top][All Lists]
Advanced

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

[avrdude-dev] Replacing exit() in library functions


From: Joerg Wunsch
Subject: [avrdude-dev] Replacing exit() in library functions
Date: Fri, 16 May 2014 18:20:29 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hello,

in order to get along a bit further the way to a possible AVRDUDE
library release, I made a big sweep across all library code, replacing
most of the calls to exit() by appropriate error return values.

For obvious reasons, library code should never call exit() unless
there is a really severe error that mandates the entire application
needs to be aborted.

I left the following instances:

. Calls to exit() after a failed malloc (and relatives); if there is
  no more memory in today's VM operating systems, normally there won't
  be any way to proceed at all.  Other portions of the code (like
  stdio) are no longer guaranteed to work then either.

  If people really think it's worth the while, we could catch these
  instances of exit() later, replacing them by something like
  malloc_failed(), to be provided by the application framework (i.e.
  by main.c in the traditional CLI tool).

. Calls to exit() in situations (in dfu.c and flip*.c) which are
  thrown in situations where some backend function reported more data
  being read than expected; in that case, some internal buffer would
  have been overflown already, so it seems best to escape from the
  application the shortest way possible.

In some cases, I had to propagate up some error code from the function
that previously called exit(), so the caller could handle the
situation.  That wasn't always possible without refactoring the code,
so there are now situations where AVRDUDE might try to continue even
though a previous error was detected.

The worst offender here is the buspirate code, which was scattered
with calls to exit() all over the place.  I tried my best, but I don't
know enough of the buspirate stuff to properly handle that myself.
Anyone who owns that hardware should make some thorough testing again,
and suggest improvements where possible.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

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



reply via email to

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