Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior To : comp.programming.threads,comp.std.c From : David Schwartz Date : Tue Feb 22 2005 12:20 pm "Douglas A. Gwyn" wrote in message news:421B4681.C50D3CCC@null.net... >> Doesn't matter, since C has no race conditions. > > Race conditions have nothing to do with conformance. No, my point is that it's bogus to try to apply the C standard's definition of conformance to programs that involve race conditions among threads because the C standard's definition of conformance was never intended to address that issue because the C standard has no race conditions. Because the POSIX standard does (for example, mutex acquisition order is unspecified), its definition of conformance is difference. Specifically, it's appropriate to addressing the issue of race conditions due to unspecified behavior. > Anyway, the Standard C spec does allow for a program > (think "thread") to have data modified by external > influences (perhaps another thread), associated with > volatile qualification. It also supports limited > operations on shared data by asynchronous signal > handlers. Sure, except it does not provide methods that are either required or sufficient for data modified by another thread. It never tried to. > Since I am reading this in comp.std.c, I assumed that > "strictly conforming program" was to be understood in > that context. According to the cited spec, the correct > terminology for the other context would be "strictly > conforming POSIX application". Note that it says that > a strictly conforming POSIX application shall not > produce any output depending on behavior described by > the C standard as implementation-defined (or unspecified > or undefined), which happens to differ from what it > requires in connection with POSIX behavior described > using the terms "implementation-defined" or "unspecified". Your definition of a "strictly conforming program" would then not include any program that uses anything from POSIX. >> Right, so that's obviously not what we're talking about, is it? > > If you used the proper terminology it would have been > easier to determine what you're talking about. The thread was not that hard to follow. We were talking about multithreaded programs. If we meant strictly conforming to the C standard, obviously none would apply. The point, however, is that every multithreaded program invokes undefined behavior from the C standard. So if something from the C standard fails to work in that context, it's actually the POSIX standard that's being violated (since it requires things from the C standard to work in multithreaded code). DS .