Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior To : comp.programming.threads,comp.std.c From : Douglas A. Gwyn Date : Tue Feb 22 2005 08:13 am <421626A9.9A55BEFB@null.net> Mime-Version: 1.0 Date: Tue, 22 Feb 2005 15:21:41 GMT X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) Xref: newsmst01a.news.prodigy.com comp.programming.threads:48971 comp.std.c:66640 David Hopwood wrote: > Doug Gwyn argues that the "strictly conforming" category is needed to > define implementation conformance. If his argument were correct it would > also apply to both plain C99 and POSIX C99. However it is not correct: > the requirements imposed by C99 4 #3 are a *strict superset* of those > imposed for strictly conforming programs. Insofar as the C standard goes, what I said was accurate. The category of s.c. program is precisely what any conforming C implementation must accept (C99 clause 4 paragraph 6). Program "correctness" has no conformance ramifications. As far as POSIX goes, their terms mean something else and you cannot figure it out from reference to the C standard. > Apart from its definition, the only other use of the term "strictly > conforming" in C99 is in clause 4 #6, which says that "A conforming > implementation may have extensions (including additional library functions), > provided they do not alter the behavior of any strictly conforming program." It says more than that about s.c. programs. > However, it appears that the intent was that extensions should also not > alter the set of *possible* behaviours of programs covered by 4 #3 > (otherwise, 4 #3 would have no force at all). No, it means what it says. For example, conforming implementations have to be very careful what identifiers they use in functions that they add to standard headers. A conforming C implementation *cannot* define popen in , to take a common extension, except when the program does something not allowed in a s.c. program, such as #defining _POSIX_SOURCE. > IOW, the "strictly conforming" category could be removed from the standard > and 4 #6 corrected appropriately, without any ill effects. Not at all. "strictly conforming program" is *the* crucial conformance category for the C standard. > More precisely, the Standard C rules have to be interpreted somehow as > applying to single threads, even though the entities being manipulated > by each thread can only be properly defined in a language model that > takes concurrency into account. This is one of the weakest areas of the > POSIX specification -- hence the interminable arguments about volatile, Fortunately, since POSIX thread creation always occurs within a new function context, the problem isn't as severe as in other environments where thread creation is more like a fork. > > There was a lot of dispute in a thread a few months ago about > > whether volatile qualification is necessary for accesses to > > shared objects. My reading of the POSIX thread spec says yes, > > others say no. In any case, you'd better interlock such > > accesses using the functions POSIX provides for that purpose. > > (The specific argument was whether such interlock functions > > also flushed any cached values. I find it hard to believe > > that that could be the intent, since it's not obvious that > > such a requirement could be met on many reasonable platforms.) > As I pointed out at the time, it cannot have anything to do with > "flushing cached values", since POSIX and C99 have no concept of > "caching" values. It is one thing to understand how a possible > class of implementations would work, and quite another to understand > what the semantic requirements are; you seem to be confusing one for > the other. Actually, no. In fact C99 carefully allows a considerable amount of value caching, although it doesn't explicitly use that *term*. The real issue is whether, as some have argued, POSIX intentionally constrains C implementations to always generate quite suboptimal (noncached) code, or to take special account of thread contexts and suppress such caching when it might matter, or not to do anything special when compiling POSIX apps. It was a real stretch to interpret the small amount said in a general introduction to the POSIX specs for the explicit interlocking (mutex) functions as applying to the compiler instead of to what those functions themselves do. .