Re: thread-safety definition
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: thread-safety definition



Gabriel Dos Reis <gdr@xxxxxxxxxxxxxxxxxxxxxxxx> writes:

> Well, let me rephrase what I was saying.
>
> From language point of view, it is permitted to do catch(...) without
> rethrowing. From practical point of view one may declare such style
> either utterly nonsense or blessed.  Either way, that working
> assumption should be stated clearly, .e.g.
>
>    This POSIX binding specification assumes that a catch-all handler
>    that does not rethrow belongs to hell.
>
> or
>
>    In this POSIX binding specification, a catch-all handler that does
>    rethrow has a blessed behaviour. 
   ^------"not" ?
>
> Such clear statement, from portability point of view, has different
> impact than an unspoken assumption.

I think I heard what you were trying to say.  Maybe I'm just blind to
the answer, but while I think it's possible (though usually
unconstructive) to formally label a particular programming construct
evil, I don't think it's possible to formally bless a programming
construct.  Whether "catch-all without rethrow", or "while(1) loop
without break", or "delete this", etc are going to be OK is dependent
on program context, even if it is OK "in principle" in the POSIX
environment.  What can a formal specification say to bless a
programming construct that could, depending on how it's used, lead to
undefined or otherwise bad behavior?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com