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: Wed, 06 May 2026 21:41:46 -0700 Organization: A noiseless patient Spider Lines: 29 Message-ID: <86jytfvnjp.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10tc902$7oav$6@dont-email.me> <10tcr8o$qc4$1@reader1.panix.com> <10tdu47$pms4$3@kst.eternal-september.org> <10tgqgk$rpk$1@reader1.panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 07 May 2026 04:41:47 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1825540"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/j7lw4Ye1CJq1OxwO0KZ25hE6hK9hdmO8="; posting-host="a025a3924a4370d705b785ca24b22822" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:F+Ea3Vm/Au4Gx0bcikg6L0zwFF4= sha1:TPUF0BKUOm2Qc44RTDo1E6xsmRk= sha256:Vswj05X3aF9wcF/BgPrFBhGiKpSgpESKQwkJv192uG0= sha1:3E4fpPwvETNReQXswBpCpoIw3AQ= Xref: csiph.com comp.lang.c:398431 cross@spitfire.i.gajendra.net (Dan Cross) writes: [...] > Another example I saw a few years ago, pre-pandemic, was an > instance of LLVM lowering storage of a volatile-qualified struct > type that was, IIRC, 7 bytes long into two 32-bit stores. The > problem was that these stores overlapped one another, with the > effect that one byte was written twice. I am friends with > some of the LLVM/clang devs, and at the time I sat in an office > down the hall from them. We were talking about it after lunch > one day, and all of us agreed that the behavior was wrong, but > the LLVM folks pointed out that it was not illegal as far as the > standard was concerned because the semantics of `volatile` were > basically unspecified (the standard was/is very unclear on this) > and non-portable, and thus a credible argument could be made > that this fell fall under the definition of UB, so technically > the compiler wasn't incorrect. Please tell them that they are wrong. "What constitutes an access to an object that has volatile-qualified type is implementation-defined." That wording hasn't changed since the original C standard. For their conclusion to be correct, they must be able to point to documentation that describes what actions the compiler will put into effect, and that what the described actions are matches what the compiler actually did. Moreover such documentation is an essential part of the implementation; without it the claim is wrong no matter what the compiler does.