Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior To : comp.programming.threads From : David Hopwood Date : Fri Feb 18 2005 09:23 am David Schwartz wrote: > Let me say this one more time another way, because it's important. A > program is strictly-conforming if it cannot be broken by changing it from > one implementation of a standard to another. No. You're assuming precisely the property that is in dispute: that only strictly conforming programs are relevant to implementation conformance. > Any program that invokes > undefined behavior is not strictly-conforming, because it can crash on one > implementation and not on another (unless crashing is considered not to be > broken). If a standard says you can do A or B and leaves which one > unspecified, a strictly-conforming program must not work in the case of A > and not work in the case of B. > > If a program had to perform identically, and produce identical output > under all possible API implementations, it would be nearly impossible to > write useful programs that strictly-conformed to POSIX. It *is* nearly impossible to write useful programs that strictly conform to POSIX. Fortunately, this is not a problem because of clause 4 #3. > 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. > 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". -- David Hopwood .