Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior To : comp.programming.threads,comp.std.c From : Douglas A. Gwyn Date : Tue Feb 22 2005 02:49 pm David Schwartz wrote: > "Douglas A. Gwyn" wrote... > > David Schwartz wrote: > >> The standard does not say that output cannot depend upon > >> implementation-defined behavior. If it did, then no useful POSIX strictly > >> conforming program could be written. > > The C standard certainly says that about a s.c. program. > Doesn't matter, since C has no race conditions. Race conditions have nothing to do with conformance. 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. > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html#tag_02_02_01 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". > 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. .