Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Future of C
Date: Mon, 19 Mar 2018 14:48:24 -0700
Organization: None to speak of
Lines: 37
Message-ID: <lnefkfrb2v.fsf@kst-u.example.com>
References: <0231327b-9e28-46e4-9178-46c881a8dd91@googlegroups.com> <40d27639-bea8-460a-add2-f5ad2f26cbdc@googlegroups.com> <p8bh23$bqk$1@dont-email.me> <5e80c990-fe53-4d7e-8a81-bc411cc21d76@googlegroups.com> <lnvady8oa0.fsf@kst-u.example.com> <2ac9ccf7-5b25-4822-8dbd-5b749bed2c07@googlegroups.com> <lnr2om8kc1.fsf@kst-u.example.com> <f0c0d057-6c7e-47bf-a10e-c6a7184da614@googlegroups.com> <lnin9y8f84.fsf@kst-u.example.com> <de720f51-a9a2-4cd9-aa29-2b622525bfc2@googlegroups.com> <lnefkm8ajm.fsf@kst-u.example.com> <c8a59d40-54c5-47e6-8474-8b8d1b86742d@googlegroups.com> <ln1sgl8d5d.fsf@kst-u.example.com> <08f373de-3438-464d-a52b-77af9564b4bf@googlegroups.com> <lnbmfp6rnr.fsf@kst-u.example.com> <5c5db803-cf2f-4e80-965b-c4950403e362@googlegroups.com> <ln4llh6kku.fsf@kst-u.example.com> <d38b0c9d-25fb-41fd-b9f6-9b0468fd18fb@googlegroups.com> <lnzi395498.fsf@kst-u.example.com> <kfnr2oioaly.fsf@x-alumni2.alumni.caltech.edu> <4ed444ae-95c3-4cbe-9659-b4f26c13b2f7@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="a28119ad63bd94f1fce4a48f9087493e"; logging-data="3698"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/IyT3em7oZvh8NuFTp2AuM"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:qGvScYSuXFmd2KBz7PS1XjKUv+Y= sha1:2rFuQF/Klcz/nzQL9TkW6b286nU=
Xref: csiph.com comp.lang.c:128038

supercat@casperkitty.com writes:
> On Saturday, March 17, 2018 at 12:50:10 PM UTC-5, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>> 
>> >> [considering making a change re: the "one program rule"]
>> >
>> > [...] I don't believe it's either practical or necessary.  The
>> > "OPR loophole" is not a problem in practice.
>> 
>> Wholeheartedly agree.
>
> Is a program that uses 10-deep recursion "portable"?  How about one that
> uses 1000-deep recursion?  How about 1000000-deep recursion?

Any program can run into resource limits on a sufficiently small system.
There is no N for which we can reasonably say that a program that uses
N-deep recursion is portable while one that uses N+1-deep recursion is
not.

> Unless one unreasonably restricts the abilities of "portable" programs,
> small machines are going to be unable to run "portable" programs designed
> for larger ones.  Having a program which will either run usefully or fail
> in predictable fashion would seem rather more useful than simply saying
> that on any particular implementation a program might run usefully or might
> behave in totally arbitrary and unpredictable fashion.

So for the specific case of deep recursion, you want a program
that recurses more deeply than the system can handle to "fail in
predictable fashion", right?  Wouldn't that imply that all conforming
implementations must insert checking code for every construct that
grows the stack, with all the overhead that implies?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"