> 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. > 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. > Thanks for your clarification. 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? How many software developers do deal with the nasty design details for signal handler implementations correctly? Regards, Markus -- 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