Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior
To   : comp.programming.threads,comp.std.c
From : James Kuyper
Date : Tue Feb 22 2005 04:06 pm

David Schwartz wrote:
> "Douglas A. Gwyn" <DAGwyn@null.net> wrote in message 
> news:421B4681.C50D3CCC@null.net...
....
>>Since I am reading this in comp.std.c, I assumed that
>>"strictly conforming program" was to be understood in
>>that context.  According to the cited spec, the correct
>>terminology for the other context would be "strictly
>>conforming POSIX application".  Note that it says that
>>a strictly conforming POSIX application shall not
>>produce any output depending on behavior described by
>>the C standard as implementation-defined (or unspecified
>>or undefined), which happens to differ from what it
>>requires in connection with POSIX behavior described
>>using the terms "implementation-defined" or "unspecified".
> 
> 
>     Your definition of a "strictly conforming program" would then not 
> include any program that uses anything from POSIX.

It's not "his" definition, it's the definition contained in the C 
standard, and is therefore the definition that applies by default in 
comp.std.c. If a message is going to be cross-posted to comp.std.c, it 
should be written to use C jargon only when the C standard meaning is 
the intended meaning of that jargon.
You're correct; a program that makes any non-trivial use of POSIX is not 
a strictly conforming C program.

>>If you used the proper terminology it would have been
>>easier to determine what you're talking about.
> 
> 
>     The thread was not that hard to follow. We were talking about 
> multithreaded programs. If we meant strictly conforming to the C standard, 
> obviously none would apply.
> 
>     The point, however, is that every multithreaded program invokes 
> undefined behavior from the C standard.

That's not because of the multi-threading per se; it's because of the 
particular methods used for putting it under user control. A compiler 
could, in principle, analyses a strictly conforming C program, and 
recognize that it's possible to translate that program in a way that 
takes advantage of the multi-threaded capabilities of a given platform, 
while producing exactly the behavior required by the C standard. That's 
admittedly a very trivial form of multi-threading, but it demonstrates 
that multi-threading alone isn't the cause of the problem.

Of course, that method doesn't put multi-threading under user control. A 
method that would put it under user control, while involving nothing 
worse than implementation-defined behavior, would be the use of #pragmas 
to control multi-threading (6.10.6).

.