Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior
To   : comp.programming.threads,comp.std.c
From : David Hopwood
Date : Fri Feb 18 2005 08:51 am

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

Note that what the program is *intended* to do is not relevant.
Suppose we change the puts() call to the following:

     puts(((char) -1) < 0 ? "char is unsigned" : "char is signed");

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.

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

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

> It's incorrect if an output of "1" is valid but an output
> of "2" is invalid. The standard has no way to say what is correct output and
> what is not, because that's a purely application-specific issue.

Right, so considering which programs are "correct" is a red herring.
*All* programs that may have unspecified or implementation-defined, but
not undefined, behaviour are potentially relevant to implementation
conformance.

(Let's leave locale-defined behaviour and implementation limits aside for
the time being.)

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

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

.