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 16:33 -0700
Organization	None to speak of
Message-ID	<87h6o51rts.fsf@nosuchdomain.example.com> (permalink)
References	<1262755563@f172.n1.z21.fsxnet> <A5pKM.1180698$TPw2.694138@fx17.iad>

Show all headers | View raw

Richard Damon <Richard@Damon-Family.org> writes:
> On 9/5/23 11:53 PM, candycane wrote:
>>   KK> This doesn't:
>>   KK>   int fred(void)
>>   KK>   {
>>   KK>     while (1) {
>>   KK>     }
>>   KK>   }
>>   KK> The previous one will be a nuisance diagnosic since the
>> always_true
>>   KK> function always returns true.
>>   KK> If the belief is correct, why not restructure the code:
>>   KK>   int fred(void)
>>   KK>   {
>>   KK>     extern int always_true(void);
>>   KK>     for (;;) {
>>   KK>       always_true(); // call for its side effect only
>>   KK>     }
>>   KK>   }
>> I may be reading this wrong, but aren't you getting into the Halting
>> Problem at this point?
>
> Fulling solving the problem would be the Halting Problem, but there
> are shortcuts that can get the vast majority.
>
> Mark functions that don't ever return with -Noreturn or [[noreturn]]
> (or an equivalent).
>
> Assume loops with a non-constant control expression will at some point
> terminate (yes, this isn't strictly true, but is a reasonable 
> assumption, and is made elsewhere in the standard).
>
> Since the above program has a for loop with an always true condition,
> that can be assumed never to end (since there is no "break" in the
> loop).

It's not necessary to assume that such loops always terminate.  Just
don't assume anything one way or the other.

For example:

    int fred(void) {
        while (1) {
            ;
        }
    }

Since the condition is a constant expression, a reasonably clever
compiler can prove that the closing } is unreachable, so no warning is
necessary.  But:

    int barney(void) {
        while (some_function()) {
            ;
        }
    }

Since the condition is not constant, the compiler doesn't know whether
the closing } is reachable.  If, as I've suggested, C were to adopt the
C# rules, a diagnostic message would be mandatory, because the closing }
*might* be reached.  (Even if the compiler is able to determine that
some_function() always returns 1, because it's defined in the same
translation unit, the diagnostic message would still be required.)

In other words, define a straightforward set of rules for determining
whether a point in the code (particularly the closing } of a non-void
function other than main) is potentially reachable, rules that do not
make any assumptions about non-constant values.

Such a change to C would break some existing code. That's absolutely a
valid reason to oppose it.  On the other hand, every major edition of
the C standard has broken some existing code, and compilers have always
supported older versions and/or used non-fatal warnings, so such code
would not be *fatally* broken.

With the C# rules, there are some unavoidable false positives, such as:

    int sign(int n) {
        if (n <  0) return -1;
        if (n == 0) return 0;
        if (n >  0) return 1;
    }

which are fairly easy to "fix".  There are, if I'm not mistaken, no
false negatives.

-- 
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 | Next — Previous in thread | Next in thread | Find similar

Thread

Re: bart again (UCX64) candycane@f172.n1.z21.fsxnet (candycane) - 2023-09-06 19:53 +1300
  Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 12:00 -0700
    Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:33 -0700
      Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 20:55 -0700
        Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 22:16 -0700
          Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-08 07:09 +0000
            Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 10:10 +0200
              Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 01:30 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:26 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 10:44 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 13:26 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:57 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:36 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 18:19 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 13:28 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-10 13:20 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 15:19 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-10 16:07 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 18:33 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-10 15:44 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 18:36 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:48 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 19:04 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 02:47 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:03 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 16:06 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-09 01:52 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 18:16 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-09 21:31 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 12:03 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 02:17 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 14:44 +0200
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-08 14:36 +0000
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:50 +0000
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-09 15:40 +0000
          Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 09:57 +0200
          Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-09 10:23 -0700

csiph-web