--- Gerhard Fiedler <lists@connectionbrazil.com>
wrote:

> 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
> 
  I agree on this matter. When it comes to
undocumented "features" reading asm listing is the
best way!

John


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist