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: Fri, 08 May 2026 15:41:58 -0700 Organization: A noiseless patient Spider Lines: 56 Message-ID: <864ikhttft.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10tdu47$pms4$3@kst.eternal-september.org> <10tgqgk$rpk$1@reader1.panix.com> <86jytfvnjp.fsf@linuxsc.com> <10tl9t3$gts$1@reader1.panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 08 May 2026 22:41:59 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3407938"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fbGLS5yRwroQK4+iBALuFOM4pKmFk7sE="; posting-host="12a84863e630bdf33525bc8ffa10a418" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:BIdi5ldAoNtndNlHnSAlbydsB7w= sha1:RT5Te4vBP2hDHOKlAzNgfc7WJeg= sha256:y2xoXbfMSWbEOa1uPVx4i5QfDml86peEvjbEfi5DVNM= sha1:9VtcQ7OrU/d89RnqX2fcgP6Vmfw= Xref: csiph.com comp.lang.c:398546 cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86jytfvnjp.fsf@linuxsc.com>, > Tim Rentsch wrote: > >> 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. > > This was almost a decade ago. [...] Sorry, I didn't mean to imply a specific physical action. My intent was simply to choose a polite phrasing. >> "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. > > That wasn't the issue. > > The issue was that the the generated code accessed the object in > a way that the overlapped write had observable side effects on > the target platform. From the perspective of the compiler > maintainers, that was obviously incorrect. > > However, the way `volatile` was defined, the behavior was not > obviously in violation of the standard. > > [subsequent comments omitted] It is unless they can point to the document that goes with the compiler that describes how volatile works in a way that agrees with what their compiler was doing. That's all I'm saying. I see from your later comments that your point was about something different, and that's fine. I wasn't meaning to contradict you, just explain something about what the C standard requires.