Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Safety of casting from 'long' to 'int' Date: Sun, 10 May 2026 09:14:43 -0700 Organization: A noiseless patient Spider Lines: 79 Message-ID: <86a4u7s0lo.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <86se89xtb8.fsf@linuxsc.com> <20260503082605.000073dc@yahoo.com> <86o6isuegr.fsf@linuxsc.com> <10tlh5r$9io$1@reader1.panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 10 May 2026 16:14:46 +0000 (UTC) Injection-Info: dont-email.me; logging-data="540864"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19WHIM3/u0QafOXYXCnSR7A3euulznpNDY="; posting-host="6036d710c83bf18720fd516086d32b65" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:KW5vBCSr5YKTOsbaulj47mK/jkA= sha1:9NMPmMXykoq3aeOjqLP8LZhpENc= sha256:N26d1SAYYzO7FlWTmM516FNE28YAqixeZY+SrordPKI= sha1:alu9rc0E9u4Lt2i/6tMsmFIOu1M= Xref: csiph.com comp.lang.c:398653 cross@spitfire.i.gajendra.net (Dan Cross) writes: [..I am summarizing parts in an effort to get to key aspects..] > In article <86o6isuegr.fsf@linuxsc.com>, > Tim Rentsch wrote: > >> [snip] >> It's important to understand the perspectives of different groups >> of participants in the C ecosystem. There are three main groups: >> >> If you're a programmer, you hate undefined behavior, and avoid it >> like the plague. >> >> If you're a compiler writer, you love undefined behavior, because >> it lets you do whatever you want. >> >> If you're a member of the ISO C standards committee (and I admit >> that to a degree I am speculating here), you think of undefined >> behavior as a balancing test, of needing to weigh the tensions >> inherent in what the first two groups would prefer. > > This, I think, is the tragedy of C ("tragedy" in the dramatic, > Shakespearean sense). > [long exposition on the history of C] > > My point here is that the users and developers of the language > were the same group, [elaboration] > > But, as you pointed out, this is no longer the case. The two are > now distinct, with very different goals. [a consequence of which > is C usage is less uniform (my paraphrase)] > > I think this is fair: pretty much no production OS is written in > pure ISO C, if they're written in C at all: they all use compiler > flags or custom toolchains to enable various extensions and pin > down aspects of UB they depend on in one form or another. > > And this is the tragedy. This isn't how it started, and I don't > think the folks who created the language wanted it to go down this > way, but here we are. [rest omitted] I wouldn't call it a tragedy, in fact just the opposite. If C had stayed in its original environment it never would have become as ubiquitous and widespread as it is today. The original ecosystem doesn't scale. By letting C, and also Unix, enter the public sphere, a great benefit accrued to the world at large. A key component of that benefit is allowing variability. Different environments make different assumptions about how things should work. Other languages, and other systems, maintain proprietary control, partially in the interest of keeping things uniform, and haven't been nearly as successful. The C community becoming more diverse is a good thing, not a bad thing. Similarly the C standardization efforts strengthened the language rather than weaken it. That's because the original authors had the foresight to allow some variation rather than insisting on complete uniformity. During the 1980s it was common to see C code littered with #ifdef's. These days, although there are still occasions when some code needs to be platform specific, they occur much less often than they do pre-standardization. As for operating systems not being written in "pure" ISO C, that's because operating systems need access to the hardware that most programs don't need and shouldn't have. Also some of that is historical artifact. Linux, to give a prominent example, was written starting in the early 1990s, before C99 introduced inline functions, and so the linux kernel allows the use of "statement expressions" in gcc; these days such constructs can be supplied using inline functions, perhaps also with generic type facilities that were added to C starting in C11. Moreover such non-standard language usages are not limited to C -- the Rust language is also used in the linux kernel, and there too some non-standard language features are used in kernel code. I don't mean to compare C and Rust. My position here is only that, in my view, the complaints raised about C are misplaced. Others are welcome to their own views on the subject.