57f
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 01:04 pm


"James Kuyper" <kuyper@saicmodis.com> wrote in message 
news:42164E25.5040207@saicmodis.com...

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

    Except POSIX does not define "strictly conforming" behavior that way. 
The C standard does, because it has no race conditions. (And frankly, the 
POSIX standard has a much more useful definition of "strictly conforming", 
IMO. Not to fault the C standard, it had different problems to solve.)

    No C program that uses POSIX threads can be strictly-conforming to the C 
standard, obviously.

    For POSIX, a "strictly conforming" program is one that can't be broken 
by implementation decisions allowed by the standard. Unfortunately, the 
standard can't really define "broken".

    I can't understand why other people are talking about the meaning of 
"strictly conforming" in the C/C++ standards when we're talking about 
multithreaded programs. This shouldn't even be on comp.std.c.

    DS

.

0