[Top][All Lists]

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

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

From: Georg von Zengen
Subject: Re: [avrdude-dev] Replacing exit() in library functions
Date: Fri, 16 May 2014 21:23:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0


an AVRDUDE library would be nice I think.
But a library should never call exit(), in my opinion. It makes debugging more complicated than necessary. And even if it is not possible to proceed the decision what to do should be left to the application developer.


On 16.05.2014 18:20, Joerg Wunsch wrote:

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.

reply via email to

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