On Wed, Feb 03, 2010 at 11:20:30AM +0100, Markus Elfring wrote: > > I don't think anyone here is much interested in whether there is any > > sort of guarantee on a particular construct working. > > That is a pity. - I would expect that professional software development > will build on working specifications instead of potentially undefined > behaviour. I think it is simply impractical. It's not that we're ignoring a specification, it's that there _isn't_ a concrete specification for the set of systems we're interested in. > > So to answer your question, I honestly don't know. The code may well > > be broken on common platforms and it is simply a race condition that > > has never come up. But I do know that it has not been a common source > > of bug reports, which makes me not want to spend time investigating > > it when nobody has demonstrated its incorrectness beyond mentioning > > a standards document. > [...] > I find that programming errors in this area might be hard to identify > from the outside because resulting race conditions and deadlocks fall > into the symptom category of heisenbugs, don't they? Yes, they can be hard to identify from the outside. But if you are interested in addressing the situation, I am suggesting that the first step would be to demonstrate that there in fact _is_ a race condition, and it is not simply some theoretical problem. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html