Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: bart again (UCX64)
Date: Sun, 03 Sep 2023 18:01:57 -0700
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <86o7iipx8a.fsf@linuxsc.com>
References: <b74c088d-09e6-4842-8b6c-1921d68154c7n@googlegroups.com> <ucprpd$38s6i$1@dont-email.me> <ucq1gd$39q14$1@dont-email.me> <ucq86h$3auvq$1@dont-email.me> <ucqj27$3con1$1@dont-email.me> <ucqpgp$3dnop$1@dont-email.me> <aa8IM.249421$f7Ub.27491@fx47.iad> <ucr3kb$3f58o$1@dont-email.me> <ucs9pb$3nd9i$1@dont-email.me> <ucsg9u$3ofr6$1@dont-email.me> <20230901104426.371@kylheku.com> <uct9hv$3v1lb$2@dont-email.me> <20230901114625.198@kylheku.com> <ucthrb$gvk$2@dont-email.me> <20230901135123.702@kylheku.com> <uctlpv$17t5$1@dont-email.me> <878r9p7b13.fsf@nosuchdomain.example.com> <ucvmqm$fb08$6@dont-email.me> <87msy46y4n.fsf@nosuchdomain.example.com> <86v8crr4p3.fsf@linuxsc.com> <20230903110003.361@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="e731bbb82483d3b3451e3d39a3921e01"; logging-data="1207069"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+9e7MLtEQ3m9kxsDgxf/Mv52ou6nHIrOY="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:j9yKiZ1leMt2rV4YMzqfrjSx+RU= sha1:c0O1iNDCwYQpO3Pk8oAKLT7ZqHg=
Xref: csiph.com comp.lang.c:173850

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-03, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>> I wouldn't mind if a future edition of the C standard added a
>>> requirement that the } of a non-void function must be unreachable
>>> (with an exception for main()).  There are languages that have such
>>> a requirement, and in my limited experience it works pretty well.
>>>
>>> The problem is that such a requirement requires the compiler
>>> to perform control flow analysis that's not otherwise required.
>>> [...]
>>
>> The problem is that in C such a determination cannot be made
>> precisely, for reasons that are both theoretical and practical.
>> Only heuristics are possible, but requirements in the C standard
>> are never stated in terms of heuristics (and rightly so).
>
> I believe this is false on both counts.
>
> There is nothing imprecise about "heuristics".  What heuristics
> aren't is "accurate".  [...]

Stop quibbling.  The point is that any proposed rule will
sometimes give wrong answers, because there is no way for
any computable function to give correct assessments in all
cases.