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: Thu, 14 May 2026 09:44:02 -0700 Organization: A noiseless patient Spider Lines: 55 Message-ID: <86cxyyhrfx.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10tvc31$mun$1@reader1.panix.com> <10tvdne$20o1q$2@dont-email.me> <10u1j2h$1l93l$31@dont-email.me> <10u21v6$ev2$1@reader1.panix.com> <10u36pv$1l93k$18@dont-email.me> <86h5oahuj3.fsf@linuxsc.com> <10u4rjf$fa5v$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 14 May 2026 16:44:05 +0000 (UTC) Injection-Info: dont-email.me; logging-data="579090"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ziMsEStvr26XIRkMgNHEQDCZtcT/AFVI="; posting-host="d527bc7f7e7e084b0e2324cbe71ceb59" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:/vfUGhTtFSVNqZdn/5up6hUrD6k= sha1:5MVQiT23ZBWrV/m6zfcTT7AoUv4= sha256:xaHLuS8h2laOBiS/wSr9uCkfI/ooI/SmqCEo1O1NQvU= sha1:Zt0zed7m0ALik0VIASuhno/8tcU= Xref: csiph.com comp.lang.c:398953 Bart writes: > On 14/05/2026 16:37, Tim Rentsch wrote: > >> Janis Papanagnou writes: >> >> [..discussing C expression syntax..] >> >>> [...] [Remembering precedence in C is difficult because of] >>> a mis-ranking of a class of operators in "C". (I noticed that >>> already when I read K&R some time around 1985, but I first saw >>> that "officially" acknowledged not too long ago when someone >>> posted a link to a paper from, IIRC, some time in the 1990's >>> written by one of the authors of "C".) - And that discrepancy >>> detail in C's precedence ranking was actually the only reason >>> for me looking "regularly" into the precedence table of my K&R. >>> (The point is that - with the exception of & ^ | - the ranking >>> makes perfectly sense and should be easily usable without doubt >>> by a concept-knowing programmer. But note that, historically, >>> a sort of "rationale" can be formulated for the discrepancy to >>> justify the given choice in context of specifically "C". But >>> still remember the "official" acknowledgement of an issue here.) >> >> I think it's easy to remember how expressions in C work with the >> help of just a few memory aids: >> >> 1. unary operators are always ahead of binary operators, first >> those on the right and then those on the left; > > Unary operators aren't the problem. It's a mystery why they need to be > in a table at all. Nobody's going to think that '&a + b' means '&(a + > b)'. > >> 3. sizeof is greedy with respect to type names: sizeof (int)+1 >> is (sizeof (int))+1, not sizeof ((int)+1) > > This isn't a problem either: it works like a unary operator. > >> 2. the bitwise operators form a sandwich enclosing the relational >> operators and the equality operators - shift (<<,>>) on top, >> and the three kinds of logical operations (&,^,|) underneath; > > This is where the trouble starts: these make up 6 different levels. > > Combinations of & ^ | are rare enough, as bitwise operations, that > you'd use parentheses anyway. They don't need 3 separate levels. > > Comparison ones don't need 2 levels. > > And shift operators don't really need their own level either. (Since > they scale numbers just like * and /, they can be lumped in with > those. Having 'a * 8 + b' mean the same as 'a << 3 + b' makes sense; > currently they have quite different meanings.) I wasn't trying to help you. I know that's a lost cause.