Re: bart again (UCX64)

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.lang.c
Subject	Re: bart again (UCX64)
Date	2023-09-06 16:45 -0700
Organization	A noiseless patient Spider
Message-ID	<86jzt2oogh.fsf@linuxsc.com> (permalink)
References	(16 earlier) <ucvk6s$f6nb$1@dont-email.me> <r1JIM.297958$uLJb.27694@fx41.iad> <ucvuhq$gmlg$1@dont-email.me> <ud60pq$1mf0p$1@dont-email.me> <zVwJM.204220$JG_b.95531@fx39.iad>

Show all headers | View raw

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/4/23 6:38 PM, vallor wrote:
>
>> On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in
>> <ucvuhq$gmlg$1@dont-email.me>:
>>
>>> If you have a function that you know will never return (becauses
>>> it stays in a loop, or terminates, here or in a nested function),
>>> then why would you give it a return type in the first place?
>>
>> Isn't asking a C compiler to watch for interminable loops and
>> such things akin to trying to solve the halting problem?
>>
>> I mean, I'm not the smartest person in the room by far, but even
>> I know that this is, perhaps, a bit far-out...
>>
>>   ...or is it?  I could be mistaken.
>
> I think the proposal to have it look to see if something might
> happen was limited to evaluating CONSTANT values.
>
> I seem to remember that a loop with a non-constant-expression
> control expression allowed the complier to assume the loop will
> eventually end, and thus if the loop had no observable effects,
> could be optimized away, even if it turns out that the condition
> could never be met.
>
> Thus, it doesn't become a Halting Problem analysis, as loop
> termination becomes "correctly" predicted syntactic means.

You're right that what the C standard says about while() and
for() loops is only for constant control expressions (along with
some other criteria, all of which are easily staticly checkable),
and so is not a halting problem problem.

I have the sense though that what is being asked about is whether
arbitrary code in a function body might reach the closing brace
without having done a return, which is equivalent to the halting
problem.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: bart again (UCX64) vallor <vallor@cultnix.org> - 2023-09-05 01:38 +0000
  Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-04 20:05 -0700
    Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 16:45 -0700
  Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 06:49 +0000
    Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 05:30 -0700
      Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 17:16 +0000
        Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 08:47 -0700
          Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 19:57 +0100
            Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 19:01 -0700
    Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-09 01:14 -0400
      Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 05:22 +0000
  Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 12:51 +0100

csiph-web