wouter van ooijen wrote:

>> I think Peter's point is that if you use a compiler in such an
>> environment, you better make sure that what you need is explicitly
>> specified as reentrant.
> 
> That is essentially a strawman argument: bad implementations exist (or
> could exist), so the language feature is bad. 

I don't think it's necessarily a strawman argument. It's difficult to get
anything guaranteed by any software vendors these days; most things are
specified as "it's working unless it doesn't" :)  The more complex a
language is, the more difficult is it to make sure for yourself, and the
more complex it may be to find out when something doesn't work as specified
(which actually happens occasionally :). 

IMO this is one of the reasons why C has been around for so long in the
area of small embedded systems: it's a workable compromise. (Which is not
to say that other such compromises, and better ones for many situations,
exist.)


>> The exception mechanism is probably one of those possible problem spots,
>> because by definition it has one single (global) exit point -- it
>> usually ends up in main() if an exception doesn't get caught. So where
>> does that leave the not caught interrupt exception? 
> 
> I am not familiar with the semantics of propagating an exception out of
> the exception handler, ...

If I were using a compiler that supports exceptions, I would want to know
how my compiler handles this. I think if I need to be sure that exceptions
are thread-safe, I need to know how they work (internally,
implementation-wise, not how they are specified to work). Or have, for one
reason or another, a lot of confidence in the word of others (usually in
the form of good and proven documentation).

> ... but if from your interrupt hndler you will use anything that can
> throw an exception you'd better include an appropriate handler 

Exceptions may be thrown for any number of reasons, and not all have
necessarily been thrown by your code (like division by 0 or stuff like
this). Unless you can trust the compiler vendor's documentation 100% (or
your own evaluation of the compiler's source code), you probably need a
catch-all exception handler in any thread or independent interrupt code
line if your compiler may throw exceptions -- even if your code doesn't
explicitly throw any exceptions. 

One thing I have learned to appreciate when working with exceptions is a
complete documentation of all exceptions that may be thrown (or re-thrown,
or passed through) by any method (or operator, which is just a semantic
form of a method). But this is not always given. (This is the same as with
the code itself: often the documentation of the exceptions is three times
more than the documentation of the method core function. Which is probably
also the reason why it is so often incomplete...)

(FWIW, I'm not arguing against the use of exceptions -- just in case :)

Gerhard

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