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: A thought of C Date: Tue, 21 Apr 2026 21:09:03 -0700 Organization: A noiseless patient Spider Lines: 78 Message-ID: <86ik9j63hc.fsf@linuxsc.com> References: <3a3462bdd72c4ed9d392a78b7d369a7b5ccc3b04.camel@gmail.com> <10rtdpd$2g1i0$1@dont-email.me> <10rth24$2h2ls$1@dont-email.me> <10rtnud$2jfm5$1@dont-email.me> <10s01e1$384ct$1@dont-email.me> <10s06q2$39rhn$1@dont-email.me> <10s2a2u$3t0f5$1@dont-email.me> <10s2fhc$3ug5h$1@dont-email.me> <10s2h5f$3uctl$1@dont-email.me> <10s2oq0$19am$1@dont-email.me> <10s2tfe$2lvm$1@dont-email.me> <10s34f6$542f$1@dont-email.me> <10s3akj$7ajg$1@dont-email.me> <10s3otn$bk6v$1@dont-email.me> <10s5atn$2sck7$1@paganini.bofh.team> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 22 Apr 2026 04:09:04 +0000 (UTC) Injection-Info: dont-email.me; posting-host="99049ae40d76034458eb7791fd827e8a"; logging-data="2085314"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/eU5gEFsDGtxq0cqs2ktqQ/WCGkmUp+Uc=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:hWiASudXODQOFjTFSkq9EBwyJvI= sha1:rJhl854y8LTyW9DcPRpOjIMj4vA= Xref: csiph.com comp.lang.c:397777 antispam@fricas.org (Waldek Hebisch) writes: > Bart wrote: > >> On 19/04/2026 20:32, David Brown wrote: >> >>> On 19/04/2026 19:47, Bart wrote: >>> >>>> Get the value of 'b', >>> >>> You can't do that. "b" has no value. "b" is indeterminate, and >>> using its value is UB - the code has no meaning right out of the >>> gate. >>> >>> When you use "b" in an expression, you are /not/ asking C to read >>> the bits and bytes stored at the address of the object "b". You >>> are asking for the /value/ of the object "b". How the compiler >>> gets that value is up to the compiler - it can read the memory, or >>> use a stored copy in a register, or use program analysis to know >>> what the value is in some other way. And if the object "b" does >>> not have a value, you are asking the impossible. >>> >>> Try asking a human "You have two numbers, b and c. Add them. >>> What is the answer?". >> >> You have two slates A and B which someone should have wiped clean >> then written a new number on each. >> >> But that part hasn't been done; they each still have an old number >> from their last use. >> >> You can still add them together, nothing bad will happen. It just >> may be the wrong answer if the purpose of the exercise was to find >> the sum of two specific new numbers. >> >> But the purpose may also be see how good they are adding. Or in >> following instructions. >> >>>> whatever it happens to be, add the value of 'c' scaled by 8, and >>>> store the result it into 'a'. The only things to consider are >>>> that some intermediate results may lose the top bits. >>>> >>>> Is 'a = b' equally undefined? If so that C is even crazy than >>>> I'd thought. >>> >>> If "a" or "b" are indeterminate, then using them is undefined. I >>> have two things - are they the same colour? How is that supposed >>> to make sense? >>> >>> You keep thinking of objects like "b" as a section of memory with >>> a bit pattern in it. Objects are not that simple in C - C is not >>> assembly. >> >> Why ISN'T it that simple? What ghastly thing would happen if it >> was? >> >> "b" will be some location in memory or it might be some register, >> and it WILL have a value. That value happens to be unknown until >> it is initialised. >> >> So accessing it will return garbage (unless you know exactly what >> you are doing then it may be something useful). >> >> My original example was something like 'a = b + c' (I think in my >> language), converted to my IL, then expressed in very low-level C. >> >> You were concerned that in that C, the values weren't initialised. >> How would that have affected the code that C compiler generated >> from that? > > You look at trivial example, where AFAICS the best answer is: > "Compiler follows general rules, why should it make exception for > this case?". Note that in this trivial case "interesting" > behaviour could happen on exotic hardware (probably disallowed > by C23 rules, but AFAICS legal for earlier C versions). The kinds of behavior Bart is asking about has been undefined behavior for just over 15 years, since 2011 ISO C.