Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior
To   : comp.programming.threads,comp.std.c
From : David Schwartz
Date : Fri Feb 18 2005 05:29 pm


"Douglas A. Gwyn" <DAGwyn@null.net> wrote in message 
news:421654A5.B02EA299@null.net...

> 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.

> I don't think POSIX uses the term "strictly conforming".
> POSIX conformance is different from strict conformance
> to the C standard.  Indeed, a strictly conforming C
> program *cannot* use any POSIX extensions.  However,
> not all programs need be s.c.  There is also the
> useful category of a (plain) "conforming" program,
> which is accepted by some conforming C implementation,
> perhaps one that also supports POSIX extensions.

    It really doesn't help to reply to an argument with "I don't think 
that's true". Please read all of 2.2.1.

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html#tag_02_02_01

>>     So then it *is* your position that virtually no useful POSIX
>> multithreaded program is strictly conforming, since they will almost 
>> always
>> have behavior that depends upon mutex acquisition order.

> No program that uses *any* POSIX-specific feature
> can be "strictly conforming" as the term is used by
> the C standard.

    Right, so that's obviously not what we're talking about, is it?

> I don't recall POSIX requiring invariance of output
> for programs to conform to *its* standards.

    Exactly. The program must just be "correct" for any possible choice of 
unspecified behavior. However, what is "correct" is not defined by the 
standard.

    DS

.