Subj : Requirements imposed for non-strictly-conforming programs To : comp.programming.threads,comp.std.c From : David Hopwood Date : Fri Feb 18 2005 07:09 am David Schwartz wrote: > "David Hopwood" wrote: >>David Schwartz wrote: >>>"Alexander Terekhov" wrote: >>> >>>>Under C/POSIX different objects just can't have the same address. >>>>And threads share the entire address space. By definition. >>> >>> That's ridiculous. Providing no strictly-conforming code can tell the >>>difference, POSIX is silent. > >>I keep hearing this idea that POSIX (or Standard C) only imposes >>requirements for strictly-conforming code. Where does it come from? >>Can you explain why you believe it? > > Common sense. Any alternative would mean that there could only be > strictly-conforming code. Please, give me an example of how a standard could > impose requirements upon things it doesn't define. Here is the [C99] definition of "strictly conforming" (it is a definition because "strictly conforming" is in italics): # A /strictly conforming/ program shall use only those features of the # language and library specified in this International Standard.2) It # shall not produce output dependent on any unspecified, undefined, or # implementation-defined behavior, and shall not exceed any minimum # implementation limit. # # 2) A strictly conforming program can use conditional features (such as # those in annex F) provided the use is guarded by a #ifdef directive # with the appropriate macro. [example snipped] This excludes, at least, code with behaviour that is defined to be a nondeterministic choice of several alternatives (what the C standard somewhat misleadingly terms "unspecified behaviour"). But clause 4 #3 then effectively says that the implementation is nevertheless required to choose one of the alternatives each time such behaviour occurs. This occurs very frequently in all POSIX multithreaded programs, because thread scheduling is unspecified. >>C99 4 #3 definitely (although not particularly clearly) says otherwise. >>("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.") > > Sure, if it's "correct in all other aspects". This simply provides a > definition of what it means for a program to be "correct in all other > aspects". No, there is no definition of what "correct" means. The point, though, is that whatever "correct" means, this clause imposes requirements on implementations for code that is not strictly conforming. >>This is quite relevant to c.p.threads, BTW. Not imposing any requirements >>for code that has nondeterministic, i.e. unspecified, behaviour would make >>POSIX useless for multithreaded programming. ^^^^^ > > If you mean it would make C or C++ useless for multithreaded > programming, IT IS. What you need is another standard, such as the POSIX > pthreads standard, which must specifically say how the C/C++ standard is > going to apply to multithreaded code. Pay attention to what I wrote. (Apologies for not changing the subject line, BTW.) -- David Hopwood .