Subj : Re: Non-strictly-conforming and unspecified versus undefined
To   : comp.programming.threads,comp.std.c
From : Keith Thompson
Date : Fri Feb 18 2005 07:51 pm

"David Schwartz" <davids@webmaster.com> writes:
> "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.

The C standard doesn't say that output cannot depend on
implementation-defined behavior, but it explicitly says that
it can't do so in a strictly conforming program.

C99 4p5 defines the term "strictly conforming":

    A strictly conforming program shall use only those features of the
    language and library specified in this International Standard.  It
    shall not produce output dependent on any unspecified, undefined,
    or implementation-defined behavior, and shall not exceed any
    minimum implementation limit.

C99 4p3 says:

    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.

So the above program is not strictly conforming, nor is any program
that depends on any features that are defined by POSIX but not by ISO
C.  It is "correct", though.

(I suppose a POSIX-specific program could be strictly conforming if it
used a POSIX library implementation implemented entirely in strictly
conforming C.  Such an implementation is unlikely, and may not even be
possible.)

Strict conformance is a very narrow concept, and few real-world
programs are strictly conforming.  Strict conformance is useful mainly
as a constraint on implementations, not on programs -- a conforming
(hosted) implementation must accept any strictly conforming program.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

.