Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Future of C Date: Thu, 15 Mar 2018 16:05:23 -0700 Organization: None to speak of Lines: 57 Message-ID: References: <0231327b-9e28-46e4-9178-46c881a8dd91@googlegroups.com> <0iXpC.1451$kF1.89@fx41.am4> <40d27639-bea8-460a-add2-f5ad2f26cbdc@googlegroups.com> <5e80c990-fe53-4d7e-8a81-bc411cc21d76@googlegroups.com> <2ac9ccf7-5b25-4822-8dbd-5b749bed2c07@googlegroups.com> <08f373de-3438-464d-a52b-77af9564b4bf@googlegroups.com> <5c5db803-cf2f-4e80-965b-c4950403e362@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="4062d3804107f3b0a8439aa53526a52c"; logging-data="25815"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/US59cuv9PW+jJeB4134fD" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:9YCRhMbrZHr5fVMmt6BgPuKTKE4= sha1:bNWjCQlDHjVtOWHh0k3q2+2xF6E= Xref: csiph.com comp.lang.c:127898 supercat@casperkitty.com writes: > On Thursday, March 15, 2018 at 5:27:41 PM UTC-5, Keith Thompson wrote: [...] >> I've already acknowledged that non-conforming implementations can be >> useful. An implementation that doesn't support recursion at all is >> non-conforming. > > Under the OPR, a low-quality but conforming implementation could bomb > the stack in any circumstances where code might otherwise make a recursive > call. Yes. Do any implementations actually do that? If so, name one. I suggest that the One Program Rule is intended to encourage useful implementations, and that it has done that job successfully. Compiler implementers typically try not to impose fixed limits (for example, depth of parenthesized expressions is limited by memory available during parsing, not by the size of a fixed table in the compiler), and conformance to the One Program Rule falls out as a consequence of that design. See the footnote under 5.2.1.4: "Implementations should avoid imposing fixed translation limits whenever possible." >> >> > C74 was designed for certain kinds of machines. On such machines, the >> >> > value of supporting recursion will exceed the cost. [snip] I misread your original statement, which I now see was correct. I somehow managed to reverse the meaning in my head. I apologize for the confusion. >> >> > A language which is >> >> > similar to C74 but lacks recursion may be useful for many purposes on >> >> > machines for which the cost of supporting recursion would exceed the >> >> > value. >> >> >> >> Sure, not all implementations have to be conforming. If a >> >> non-conforming implementation is useful, that's great. No 64-bit >> >> integers, no recursion, no floating-point, whatever. >> > >> > Presently, the Standard does not require that implementations be capable >> > of usefully processing any programs [an implementation's One Program could >> > be contrived and useless]. >> >> Yes, yes, we know. > > Why are you so dismissive of the idea of closing the OPR loophole and > having the Standard offer unequivocal behavioral guarantees? For one thing, because you bring it up, seemingly at every opportunity, and it's gotten boring. And because I don't believe it's either practical or necessary. The "OPR loophole" is not a problem in practice. -- 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"