Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: bart again (UCX64) Date: Sun, 03 Sep 2023 03:47:26 -0700 Organization: None to speak of Lines: 50 Message-ID: <877cp77cu9.fsf@nosuchdomain.example.com> References: <557bf807-40c7-404b-9242-c26975faa42fn@googlegroups.com> <20230901104426.371@kylheku.com> <20230901114625.198@kylheku.com> <20230901135123.702@kylheku.com> <878r9p7b13.fsf@nosuchdomain.example.com> <87msy46y4n.fsf@nosuchdomain.example.com> <86v8crr4p3.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="bce9f47447e4fb1356ae9778f84e0995"; logging-data="939321"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/BnEzVWT97cVhoza29LsHF" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:GQrmpZJbZDHz5DrPHqw9LwQLhL8= sha1:a6l1PLALN2M00O707okr+AF9yHc= Xref: csiph.com comp.lang.c:173756 Tim Rentsch writes: > Keith Thompson 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). Yes, I addressed that in my previous post: I think we'd need a rigorous definition of reachability that's not too difficult to implement. It might require adding unnecessary return statements in some corner cases, but IMHO that's ok. There's precedent in other languages that C could steal. For example, the closing } in this function: int func(void) { if (rand() >= 0) return 42; } will never be reached (because rand() always returns a non-negative result), but compilers should not be required to do that level of analysis. In a future version of C that requires the closing } of a non-void function other than main() to be unreachable, I'd expect this to be diagnosted as a constraint violation, fixable by adding a return statement in an else clause or after the if statement. To put it another way, if the compiler can't prove that the closing } cannot be reached via any control path *without* making any assumptions about the values of any conditions, a diagnostic would be required. I've seen this kind of requirement in other languages, but I don't remember which ones off the top of my head. -- 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 */