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: Fri, 16 Mar 2018 10:23:58 -0700 Organization: None to speak of Lines: 62 Message-ID: References: <0231327b-9e28-46e4-9178-46c881a8dd91@googlegroups.com> <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="9d63a136047e1952cd06df9b4725c10b"; logging-data="7876"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ObLj2h7Qq7ZFnrhebfhuG" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:nMM2loqlaJqZDRzxuV2I7fhJZcg= sha1:+00x+rExlzfiFWZY8XkvhxxWUIY= Xref: csiph.com comp.lang.c:127925 supercat@casperkitty.com writes: > On Thursday, March 15, 2018 at 6:05:38 PM UTC-5, Keith Thompson wrote: >> supercat@casperkitty.com writes: >> > 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. > > My point is that failure to support recursion in any meaningful way would > not make an implementation non-conforming, if it were to pretend that it > died on recursive calls because of a translation limit. By "pretend", you mean "lie", right? If an implementation can handle non-recursive calls to a depth of, say, several hundred, but blows up on a single simple recursive call, it can *claim* that it blows up because of a translation limit, but such a claim would obviously be false. I would not call such an implementation conforming, any more than one that claims to support "long long" but claims a translation limit that doesn't permit the "long" keyword to appear more than once. Fortunately, as far as I know, no implementation actually behaves this way, so it's not an issue. It's just a hypothetical example intended to make a point that, in my opinion, is not particularly valid. >> 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." > > I think "when *practical* would have made more sense than "whenever > possible". If it would be possible to use variable-sized data structures, > but they'd run much slower than fixed-sized ones, I'd regard the fixed- > sized ones as superior for tasks where they were sufficient. I agree that "when practical" would be better, but I don't agree that it matters. Implementers want their implementations to be *useful*. They're not going to make something with horrible performance for the sake satisfying an interpretation of a non-normative footnote. And again, this is purely hypothetical. In most cases, variable-sized data structures aren't going to be much slower than fixed-size ones. (Remember we're talking about compile-time data structures, so the code doesn't have to run on an 8051.) I'm less interested in how implementations *might* be affected by edge cases like these than in how specific implementations *are* affected. [...] -- 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"