Olin Lathrop wrote:

> Joel Parker wrote:
>> The best I can tell, most people use either global variables (such as
>> errno)
> 
> Yucc.  I know Unix does this, but using a global like that is a bad
> idea, at least in code on general purpose machines where a few cycles
> don't matter. 

Right... I also prefer something that automatically wraps up the stack.
(Note that errno was invented at a time when multitasking was handled
exclusively by the OS, and each "thread" had its own errno. Which is
what multithreaded CRTs still do, and which makes it workable.)

But in a small system, this isn't necessarily a bad idea, IMO.
Especially if you split it twofold: a bit that tells you success or
failure, and a longer variable that tells you what failure. 

You have to make sure that you handle "thread" synchronization properly.
But in a small system that's generally not a problem -- you tend to not
call such functions from within an interrupt and from within the
mainline code.

>> or return codes to flag errors within each function, then check for
>> those errors once the function returns.
> 
> That's exactly what I do for my host code.  Any subroutine that could
> fail, like just about all I/O routines, returns a variable I usually
> call STAT of type SYS_ERR_T.  That is a structure that can contain my
> own subsystem code and status code within the subsystem, or it can
> indicate a system error code.  

Compared to the global variable solution, this incurs probably some
overhead, and depending on the structure of the program, it may not
bring any advantage.

Both methods can work, but don't count on any method working with 3rd
party libraries. These generally will have their own method (if any :)
to do this, and you'll just have to deal with it.

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist