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

Re: [c++-pthreads] Re: thread-safety definition



David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx> writes:

| 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.

I think, you're reading "bless" and "hell" too literally :-).

"belongs to hell" is another spelling I was using for "has
unspecified/undefined behaviour", meaning that the binding
specification does not intend to support such program as
portable. Similarly, "bless" was used  for "specified behaviour".

|  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.

Of course, and the keyword here is "in principle". 

If a binding says that "catch-all without rethrow" has undefined
behaviour under conditions foo, the only thing it means for sure is
that it is not a *portable* construct if foo do not hold.  
Even if foo are not met, the construct might be fine for the
program depending on the guarantee made by the _particular_
implementation it is using.  

And you've been doing that all the time.

| 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?

It can say under which general circumstances it has defined behaviour.

-- Gaby