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 11:36 am


"David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message 
news:40iRd.120750$B8.76775@fe3.news.blueyonder.co.uk...
> David Schwartz wrote:
>>     Programs that rely on unspecified behavior can still be
>> strictly-conforming if and only if any of the possible alternatives for 
>> the
>> unspecified behavior still produce correct output for that program.

> No, you're mistaken. Let's look at an example -- for simplicity, one in
> plain C99 rather than POSIX C99, and with implementation-defined rather
> than unspecified behaviour:
>
> #include <stdio.h>
>
> int main(int argc, char **argv) {
>     puts(((char) -1) < 0 ? "char is signed" : "char is unsigned");
>     return 0;
> }
>
> Clearly this is not a strictly conforming program, since its output
> depends on implementation-defined behaviour. Nevertheless the C99 standard
> requires it to print either "char is signed" or "char is unsigned".

    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.

> Now the program never produces correct output. That makes no difference 
> whatsoever to the conformance issue: it must still print either
> "char is signed" or "char is unsigned". It would be quite incoherent
> for the definitions of implementation conformance to depend on whether
> any program is correct in the usual sense of "producing output intended
> by the programmer", since the programmer's intent isn't an input to the
> implementation.

    I did not say "output intended by the programmer". What I said is that 
implementation decisions allowed by the standard cannot change the program 
from operating correctly to operating incorrectly.

>> This requires that the unspecified behavior invoked be one wherein the
>> standard limits the possible behaviors to a defined set.
>
> All unspecified behaviour is so limited, by definition (C99 3.4.4).

    Right.

>> 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.
>
> "valid"? That would just be describing one undefined word in terms of
> another one.

    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.

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

> What we were talking about (in the other thread) is the C standard as
> interpreted in the context of POSIX. The definitions of "strictly
> conforming", "unspecified", etc. still apply.

    There is no way for a program that invoked *undefined* behavior (which 
any multithreaded program does with respect to the *C* standard) to be 
strictly conforming.

    DS

.