Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #174478
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: bart again (UCX64) |
| Date | 2023-09-07 22:16 -0700 |
| Organization | None to speak of |
| Message-ID | <87y1hhmehf.fsf@nosuchdomain.example.com> (permalink) |
| References | <1262755563@f172.n1.z21.fsxnet> <A5pKM.1180698$TPw2.694138@fx17.iad> <87h6o51rts.fsf@nosuchdomain.example.com> <GWwKM.320358$uLJb.75975@fx41.iad> |
Richard Damon <Richard@Damon-Family.org> writes:
> On 9/7/23 4:33 PM, Keith Thompson wrote:
>> 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.
>
> Except that if you want to make falling off the end of an non-void
> function an error, you can't do that.
>
> Note, from 6.8.5 p6 which states (using N2596):
>
> An iteration statement may be assumed by the implementation to
> terminate if its controlling expression is not a constant
> expression,171) and none of the following operations are performed in
> its body, controlling expression or (in the case of a for statement)
> its expression-3:172)
> — input/output operations
> — accessing a volatile object
> — synchronization or atomic operations.
>
> This is a rule that allows optimizations to remove a loop that has no
> external effect. A similar rule could be used to determine if the end
> of the function is potentially reachable.
That does complicate things. Note that currently an implementation is
allowed but not required to "assume" that the loop terminates.
Currently, the standard never requires control flow analysis to
determine whether a constraint is violated.
I'm not sure what the best solution is. I'd like to say that 6.8.5p6
should be ignored when determining whether a diagnostic is required for
potentially reaching a closing }.
Full disclosure: I really dislike that statement in the standard, both
because of its semantics and because it's written to permit an
implementation to "assume" certain things rather than in terms of
permitted behavior.
>> 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.)
>
> Right, because we need to define the level of effort the compiler
> needs to do. And it should avoid "surprizes" as much as possible.
>
>> 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.
>>
>
> Right, and using the existing "rule" about loops with non-constant
> control expressions makes the most sense.
>
>> 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.
>
> Right. But make the function take a double instead of an int, and it
> CAN fall through (on some implementations) since there exist double
> values that are none of >0, <0 or == 0.
That's a different function. I wrote the sign() function above to make
the point I wanted to make.
> One option would be to allow an [[unreachable]] attribute to mark that
> you can't get here, even if the base rules don't prove it, and leave
> the results Undefined if you somehow do get there.
I like it. It's similar to the /*NOTREACHED*/ comment recognized by
many lint implementations.
It could be added *instead* of requiring reachability analysis, and a
programmer could add [[unreachable]] before the closing } of a non-void
function. But adding the requirement I propose would catch errors made
by programmers who don't do that.
--
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
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) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-10 21:36 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 08:51 +0200
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 23:59 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 01:01 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 11:17 +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