avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] python wrapper for avrdude


From: Joerg Wunsch
Subject: Re: [avrdude-dev] python wrapper for avrdude
Date: Thu, 5 Mar 2009 23:14:38 +0100
User-agent: Mutt/1.5.11

As address@hidden wrote:

> From the perspective of a library user I would enjoy the following
> points:

>  * compile in the default config dir as const char *,
>    so the user gets a glue where avrdude.conf is situated.

IMHO, the default config dir is not of any concern for the library.
That's entirely within the domain of the frontend application.

>  * wrapping the functions "exit" and "fprintf" in der library,
>    so for exit an exception could be thrown and fprintf could
>    be redirected for GUI based applications.

Yes, both don't belong into the library at all.  I could live with a
few fprintf(stderr, ...) in really exceptional siutations (like
malloc() returning NULL which is an almost "Can't happen" situation in
a virtual memory system).  After all, many GTK applications have a
tendency to clutter stderr with pointless warnings...

As for exit(), AVRDUDE has been coded quite sloppy in the past, with
no clear concepts about any kind of error recovery.  In various
places, callers return -1 upon error, and callees might or might not
take notice about that :), in other cases, there are "exit(1);" calls
deeply hidden within the calling tree for only slightly abnormal
situations.

I already started converting exit(X) into return -1 plus adding error
handling in the callers whenever I've been annoyed enough by the
current situation, but I'm also sure I'm far away from being done with
that.  Bug reports are welcome here, and even more welcome are
patches.  ;-)

> With Joergs points, single include file and documentation I agree
> fully.

In case a single include file becomes too impractically huge, I'd
probably switch to a separate avrdude subdirectory for include files,
so source files could use #include <avrdude/list.h> etc.  There's some
room for experiments here, but I'd first like to move everything to
SVN as this makes it easier to subsequently move things around.

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

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




reply via email to

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