c97
Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior
To   : comp.programming.threads,comp.std.c
From : James Kuyper
Date : Fri Feb 18 2005 03:20 pm

David Schwartz wrote:
> "David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message 
> news:40iRd.120750$B8.76775@fe3.news.blueyonder.co.uk...
....
>>#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.

Section 4p5: "A strictly conforming program ... shall not produce output 
dependent on ... implementation-defined behavior, ...".

> ... If it did, then no useful POSIX strictly 
> conforming program could be written.

Exactly true. The set of "Strictly conforming" programs is important for 
conveying the requirements of the C standard. It is not a category that 
contains any significant number of actually useful programs. In 
particular, it doesn't contain a single program making significant use 
of POSIX-specific features, because all such features involve behavior 
that is either unspecified, undefined, or implementation-defined  from 
the point of view of the C standard. The POSIX standard does define the 
behavior, but strict conformance is defined purely in terms of what 
behavior the C standard does or does not require of a program.

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

Well, that's true, so long as the program produces a correct output for 
every permitted choice. However, it's pretty uncommon for that to be the 
case. Poorly written code often behaves incorrectly when an 
implementation makes an unexpected choice; well-written code tends to 
produce the same behavior, regardless of which choice the implementation 
makes. Code which produces different correct behaviors depending which 
choice has been made, tends to be written solely for the purpose of 
finding out which choice has been made.

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

That's certainly one common way in which they fail to be strictly 
conforming.

.

0