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: Sat, 02 May 2026 16:50:34 -0700 Organization: A noiseless patient Spider Lines: 43 Message-ID: <86wlxlxtf9.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10sv4v0$h9mn$1@dont-email.me> <84c1c180f4d5b96259a631bdb09b6054b4eb44d2.camel@gmail.com> <10svgfv$l2bu$1@dont-email.me> <10t4hse$22u36$1@dont-email.me> <97a1c40bf71cfe8edab25d5ac8a1ad435c3995e5.camel@gmail.com> <10t4t8v$25van$1@dont-email.me> <861pftzogw.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sat, 02 May 2026 23:50:37 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2663530"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18jWQLi7rRw26PWzbruD3bxglpI38kBBow="; posting-host="0224f8b6fcff9256362aa20147bea6bc" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:stHHqnZnjK78WhRN4IsReGyADTs= sha1:JB6+6Pc0uHPFSZzfV7I2N3oLmDQ= sha256:3GmfPKw9e0uPmhZ8UOarMxYgro5qQTUd/PrRJ5UsYQY= sha1:mcYuecsMxYOIsyWGq7H8tQWZCt4= Xref: csiph.com comp.lang.c:398199 wij writes: > On Sat, 2026-05-02 at 10:54 -0700, Tim Rentsch wrote: > >> wij writes: >> >>> What does "abstract machine" mean exactly? >> >> The term "abstract machine" comes from the ISO C standard. It >> refers to an environment in which the behavior of constructs in the >> C language can be defined, and which is independent of any actual >> hardware or compiler. It's an important concept to understand, for >> anyone who wants to reason about what C programs are supposed to do, >> what they are allowed to do by the C standard, and what they are not >> allowed to do if being run on a conforming implementation of ISO C. >> >> Note that there is nothing stopping a compiler from claiming to be a >> "C compiler," even if it doesn't conform to the requirements of the >> ISO C standard. That is why it's important to understand what are >> the rules of the "abstract machine", because it allows us to talk >> about what to expect of C programs, without having to refer to how >> any particular hardware behaves, or what any particular compiler >> does, but just considering the C program itself. > > I understand it is a must with the setup of the "abstract machine.." > theory. So, according to C standard, if the compiler of 'C' > language encounters an overflow error, the 'C' compiler is free to > silently convert the erroneous code to any thing it feels like. > > Strictly speeking, the standard cannot be wrong itself, human > interpreter (expert) must spell out reasons it is 'correct' as > demonstrated (of course, it will be invalid in form of cyclic > argument). E.g. in this UB case, because it is undefined, the > compiler is not required to report this error. So, logically, UB is > not an error, neither, to be consistent. So, everything is fine to > the language 'expert'. But, actually, all are 'interpretation', not > different than what I say now. We just cannot say the standard is > wrong (sadly, my interpretation suggests so). I am not interested > in such kind of word game. You asked a question. I answered it. Don't blame me if the answer is not to your liking. If you didn't want to hear the answer you shouldn't have asked the question.