Subj : Non-strictly-conforming and unspecified versus undefined behavior
To   : comp.programming.threads
From : David Schwartz
Date : Thu Feb 17 2005 11:34 pm


    Programs that rely on unspecified behavior can still be
strictly-confirming if and only if any of the possible alternatives for the
unspecified behavior still produce correct output for that program. This
requires that the unspecified behavior invoked be one wherein the standard
limits the possible behaviors to a defined set. It cannot invoke undefined
behavior, because then it would not be "correct in all other respects".

    What the standard is doing is defining what it means for a program to be
"correct in all other respects". For example, a program that outputs "1" if
thread 1 gets a mutex and "2" if thread 2 gets a mutex is correct, if either
output is valid. It's incorrect if an output of "1" is valid but an output
of "2" is invalid. The standard has no way to say what is correct output and
what is not, because that's a purely application-specific issue.

    Note that this is about *unspecified* behavior, not *undefined*
behavior. Any program that invokes undefined behavior loses any right to
complain about anything that happens after that undefined behavior was
invoked, with respect to that particular standard.

    So if you find a case where the C standard is violated only for POSIX
multithreaded code, technically, it is the POSIX standard that is being
violated, not the C standard. The C standard doesn't say what happens with
multithreaded code.

    DS

.