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 06:59 pm


"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnmzu1i84m.fsf@nuthaus.mib.org...

> "David Schwartz" <davids@webmaster.com> writes:

>> "Douglas A. Gwyn" <DAGwyn@null.net> wrote in message
>> news:421654A5.B02EA299@null.net...

>>> No program that uses *any* POSIX-specific feature
>>> can be "strictly conforming" as the term is used by
>>> the C standard.

>>     Right, so that's obviously not what we're talking about, is it?

> No, it wasn't obvious.  This discussion is cross-posted to
> comp.programming.threads and comp.std.c.  Here in comp.std.c, since
> the C standard defines the term "strictly conforming", it's obvious to
> most of us that that's what the phrase refers to.

    I don't know who started the crosspost to comp.std.c, but it's entirely 
inappropriate.

> I didn't know until
> just recently that POSIX also uses the term (with a different meaning,
> of course); I suspect most of the comp.std.c regulars weren't aware of
> that either.

    It has to. The C definition of "strictly-conforming" is useless in a 
multithreaded case. Not that this is the fault of the C standard, it didn't 
have to tackle that problem.

    I am partly responsible for this, I'm afraid. I used the phrase "the 
standard" in a case where it's ambiguous which standard I was referring to, 
then I didn't catch that I was misunderstood.

    Please remove further followups to comp.std.c. Anything having to do 
with multithreading is not strictly-conforming to the C standard because it 
invokes undefined behavior, end of story.

    DS

.