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 15:27:29 -0700 Organization: None to speak of Lines: 62 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="18015"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18aVh8ARZ6KQWqGmqRyY55U" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:d9SuF++iabsrdRvD/MyIc0Dlxqs= sha1:5J6m/OyltGhHLLy3VZCqNpRt68c= Xref: csiph.com comp.lang.c:127896 supercat@casperkitty.com writes: >> supercat@casperkitty.com writes: >> > Does the Standard mandate any circumstances where a recursive function call >> > must succeed without stack overflow? If not, in what sense is support for >> > recursion really mandatory? >> >> You're right, nothing in C is really mandatory (other than the >> ability to translate and execute the infamous One Program), so why >> bother discussing anything about such a useless language? > > If two implementations are identical except that one hits translation > limits in cases where the other does not, the latter would be of better > quality. All else being equal, an implementation where any recursive > call would behave as though it hit a translation limit would be inferior > to one which can handle recursion in useful fashion. All else not being > equal, however, an efficient implementation that can't handle recursion > may be superior for many purposes than a less-efficient implementation > that can. I've already acknowledged that non-conforming implementations can be useful. An implementation that doesn't support recursion at all is non-conforming. >> > C74 was designed for certain kinds of machines. On such machines, the >> > value of supporting recursion will exceed the cost. >> >> Did you omit a word? "Recursive calls to any function are permissible." >> -- cman74.pdf 7.1.6. > > No. The value of support for recursion exceeds the cost of providing such > support. When the value of something exceeds the cost, it is worth > providing it. What are you talking about? The machines for which C74 was designed included the PDP-11, for which recursion was both useful and implemented. K&R1 (1978) mentions 4 target systems, all of which, if I'm not mistaken, could easily support recursion. C-like implementations for small embedded systems where recursion might not be worth implementing came later (I don't know the detailed history). >> > 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. [SNIP] -- 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"