Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior To : comp.programming.threads From : David Schwartz Date : Fri Feb 18 2005 11:39 am "David Hopwood" wrote in message news:CuiRd.130288$K7.8084@fe2.news.blueyonder.co.uk... >> On the other hand, if you were allowed race conditions, >> strictly-conforming POSIX programs could break if you changed >> POSIX-compliant platforms. > Race conditions result in undefined behaviour, not unspecified. Huh?! Race conditions result only in unspecified behavior. The POSIX standard does not say, for example, which of two threads will get a mutex, but it says that one and only one thread will get it at a time. (Race conditions are not possible in the C standard, so the C standard's definition of "strictly-confrming" doesn't apply here.) >> A program is strictly-conforming to a standard if it cannot be broken >> by any possible changes in unspecified behavior and does not invoke >> undefined behavior. > > Where are you getting these definitions? That is not what the C or POSIX > standards say, and nothing that they do say depends on the concept of > programs being "broken". "A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3." Notice it says "correct in all other aspects". This means, roughly "not broken". This is saying that race conditions do not make a program incorrect, if they don't make it behave incorrectly. DS .