Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Unspecified behavior in C Date: Sun, 12 Jul 2015 12:07:21 -0700 Organization: None to speak of Lines: 50 Message-ID: References: <353ff1a5-5e38-4791-9e5b-2c3d6589079c@googlegroups.com> <97928b10-0689-4a44-b516-56fdadf9e39a@googlegroups.com> <30dbd9ab-036d-4b2a-bcea-7538f2dbe73d@googlegroups.com> <37753968-e7fd-4076-9451-ed27b66a7330@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="23232"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ZfCHbRqHa9eKfjOxKUcRo" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:DZ/iphbTprfqoxSoNue0sLTnQCw= sha1:ala/wXgXMeRZcictyqSxxUEE/Y0= Xref: csiph.com comp.lang.c:65442 David Kleinecke writes: > On Saturday, July 11, 2015 at 5:15:58 PM UTC-7, Keith Thompson wrote: [...] >> You've answered none of the questions I asked. Did you intend to? > > Most of your questions appear rhetorical to me. I don't answer > rhetorical questions. None of those questions were rhetorical. I do not understand your position, and I'm trying to. (Or rather, I was.) >> The standard documents the language. The documentation for a >> particular implementation is likely to be useless without that >> knowledge. >> >> The C standard says that the order of evaluation of function >> arguments is unspecified. It also explains clearly what >> "unspecified" means. Apparently that's not good enough for you, >> but you haven't explained why. > > It doesn't explain what "unspecified" means other than undocumented > implementation-defined. A clearer explanation goes the other way. Unspecified behavior is behavior where the standard provides two or more possibilities. Implementation-defined behavior is a subset of unspecified behavior, where the implementation must document is choice. I find that perfectly clear. > I have suggested already that these should > be documented just like all the other implemenation-defined features. > And I have stated repeatedly that I want everything documented. Yes, you've stated it repeatedly -- and you've repeatedly failed to explain why, even given questions about specific examples. Given: f(g(), h()) the calls to g() and h() may occur in either order, and the implementation is not required to document which order it chooses. I don't know what benefit you think there would be in requiring all conforming implementations to document their choice (which may be made in a very complicated manner). -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"