Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #174422

Re: bart again (UCX64)

From Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups comp.lang.c
Subject Re: bart again (UCX64)
Date 2023-09-07 14:18 -0700
Organization None to speak of
Message-ID <87cyyt3co1.fsf@nosuchdomain.example.com> (permalink)
References (16 earlier) <b9e00c9c-e879-49d2-a00a-05256b87d766n@googlegroups.com> <87v8coqcpa.fsf@bsb.me.uk> <86zg1ymvvv.fsf@linuxsc.com> <20230906223634.465@kylheku.com> <3b850d75-ae05-4c31-a3d6-9b0333de84abn@googlegroups.com>

Show all headers | View raw


Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 7 September 2023 at 07:10:49 UTC+1, Kaz Kylheku wrote:
>> I'm quite puzzled by your angle which seems to be that if the 
>> reachability diagnostic cannot be done accurately, due to theory, 
>> translation units and run-time conditions/inputs, then it's 
>> a bad diagnostic not worth doing (or at least not worth having 
>> right in the language). Pardon me if I'm misconstruing antyhing. 
>> 
> Take this one.
>
> int gamemainloop(void)
> {
>     if (allocatememorybuffers() == -1)
>        return -1;  // out of memory;
>    if (hardwaretest() == FAIL)
>         return -2; // proper hardware not installed
>     loopforever();  // update / render loop, never returns
> }
>
> Obviously to prove that loopforever loops forever we need to examine it.

No, just declare it as:
    _Noreturn void loopforever(void);
in C11 and later, or
    [[noreturn]] void loopforever(void);
in C23.

Currently the only effect of _Noreturn is that the behavior is undefined
if the function returns, but if a future C added rules to require return
statements in non-void functions, noreturn functions could easily be
part of the analysis.

> And even if we could, its the halting problem - most real programs
> written by humans can be trivially proven to either halt or run
> forever, but it's hard to write that requirement into a programming
> language.

Nobody is suggesting that a C compiler must include a general halt
decider.

C#, in my opinion, has a reasonable set of rules for this.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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


Thread

Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 18:30 -0700
  Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 03:04 +0100
    Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 21:48 -0700
      Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 06:10 +0000
        Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-07 02:06 -0700
          Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 15:52 +0000
          Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:18 -0700
        Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 15:28 +0100
          Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 16:54 +0200
            Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:02 +0100
              Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 16:12 +0000
              Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:17 +0000
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:37 +0100
              Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:51 -0700
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 00:46 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:06 +0200
              Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 10:19 +0200
          Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 15:55 +0100
            Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 15:16 +0000
              Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:02 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:15 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:51 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:24 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:53 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:34 +0000
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:25 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:37 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:02 +0000
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:14 -0700
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:09 -0700
            Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:34 +0100
              Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:22 +0000
            Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 11:44 -0700
            Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 15:16 -0700
              Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 23:48 +0100
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 17:16 -0700
            Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:16 +0200
              Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 10:51 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 13:00 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:05 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:11 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:56 +0000
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:47 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:49 +0200
                Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-09 10:27 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 12:06 +0200
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-08 05:03 -0700
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:39 +0100
                Re: bart again (UCX64) candycanearter07 <no@thanks.net> - 2023-09-08 07:49 -0500
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:07 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:51 +0200
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:35 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:04 +0000

csiph-web