Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: do { quit; } else { } Date: Sun, 11 May 2025 19:05:41 -0700 Organization: A noiseless patient Spider Lines: 72 Message-ID: <861psuziq2.fsf@linuxsc.com> References: <868qoaeezc.fsf@linuxsc.com> <86mscqcpy1.fsf@linuxsc.com> <86iknecjz8.fsf@linuxsc.com> <86o6x5at05.fsf@linuxsc.com> <20250409170901.947@kylheku.com> <87wmbs45oa.fsf@nosuchdomain.example.com> <87semf4pw5.fsf@nosuchdomain.example.com> <87zfgn344c.fsf@nosuchdomain.example.com> <20250411142636.00006c00@yahoo.com> <20250411102119.431@kylheku.com> <20250413204521.0000238e@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 12 May 2025 04:06:00 +0200 (CEST) Injection-Info: dont-email.me; posting-host="74b4e5895be58ca73eb02e8f9ff401e1"; logging-data="921214"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX197s4X+mgV7FTI08I8nA17p2X5JVrN32lc=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:JIQOLkfXQUVNbTw/qlpXDDmMNnY= sha1:WehIzSU+caALzUpARZem1SqKzTU= Bytes: 4886 Michael S writes: > On Fri, 11 Apr 2025 17:22:37 -0000 (UTC) > Kaz Kylheku <643-408-1753@kylheku.com> wrote: > >> On 2025-04-11, Michael S wrote: >> >>> On Thu, 10 Apr 2025 17:59:15 -0700 >>> Keith Thompson wrote: >>> >>>> An understanding of what "compatible types" means. >>> >>> Bart didn't say that types are compatible or non-compatible. >>> He said that they are 'compatible enough'. That is not terminology >>> of C Standard, but terminology of his own. And he seems to >>> understand it. >>> >>> In my own translation, 'compatible enough' means that when these >>> structs are accessed then any sane or even semi-sane compiler will >>> generate code that will have the same effect as in case of access >>> through structures with literally identical declarations. >> >> so struct { long x; } and struct { int x; } are compatible enough, >> in situations that are portable enough. > > I wish they would be, but according to C Standard they are not, > ene when both represent 32-bt signed integer. That's because of > misfeature called 'strong aliasing rules'. > IMO, C would become better without this misfeature. I think this reaction is rather shortsighted. Making this change would incur several downsides, and offers no significant upside that I can see. First it would greatly complicate the language semantics. Whether a program is meaningful, and if so what the meaning is, would be much harder to state than it is now. Second it would imply that whether a program is well-defined is a lot more dependent on implementation-specific choices than it is now. Third, as a consequence of that, it would be harder to write program verification tools, because they would need to take these more extensive implementation dependencies into consideration. Fourth, there would be consequences for program optimization, and it is hard to dismiss those. Some people may not care about the optimizations losses, but certainly many people want the benefits of those optimizations. Fifth, related to the previous point, as a practical matter it would make getting the optimization benefits back again be nearly impossible. As things are now, it's easy to have a compiler option to disable the consequences of strong typing rules, and the result can still be a conforming implementation. But if the C standard would prescribe the semantics of cross-type access, then any option to ignore the implications of that prescription would necessarily make using said option result in a non-conforming implementation. To say the last point another way, with things as they are now developers can choose whether they want to observe the cross-type access restrictions, or ignore them, and still get a C compiler. If the effective type rules were discarded, there is no way to choose the more-optimizing path without getting something that is not a C compiler. Given that you can always get what you want either by choosing an appropriate compiler option (if available) or by using one of the well-known legal workarounds, I think it's hard to make a case that getting rid of the effective type restrictions is a good idea.