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: Sat, 25 Apr 2026 17:20:16 -0700 Organization: A noiseless patient Spider Lines: 62 Message-ID: <86bjf6373z.fsf@linuxsc.com> References: <3a3462bdd72c4ed9d392a78b7d369a7b5ccc3b04.camel@gmail.com> <10s3akj$7ajg$1@dont-email.me> <10s3otn$bk6v$1@dont-email.me> <10s4gtb$grfo$1@dont-email.me> <10s53k2$mlh7$1@dont-email.me> <10s9c7a$2b5i9$4@dont-email.me> <10sal4e$2967c$1@dont-email.me> <10sbera$2iai7$2@kst.eternal-september.org> <10sbl72$2knde$1@dont-email.me> <10sbue0$2mtc2$1@kst.eternal-september.org> <10scqh1$2u305$1@dont-email.me> <10se1pa$3b5kb$2@dont-email.me> <10se5r1$3c90c$1@dont-email.me> <10sehaa$3e0ld$1@dont-email.me> <10sh4sk$ge59$2@dont-email.me> <10sh5aa$ghpi$1@dont-email.me> <10siolv$t20v$1@dont-email.me> <10sj2vv$127t8$1@dont-email.me> <10sj7tj$14il7$1@dont-email.me> <86o6j63gqs.fsf@linuxsc.com> <10sjbk3$15idp$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 26 Apr 2026 00:20:17 +0000 (UTC) Injection-Info: dont-email.me; posting-host="ba9581de696c0982039c62980e84b25b"; logging-data="1310655"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198i6oQ/+VEjwtxfT2EeB7sU5Ap/cyyGwk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:hRjJrUDFgeOiw1pZTCF2ms4gWaY= sha1:+KiuqfCzH91dw/Io8W4jkEm22Xw= Xref: csiph.com comp.lang.c:397963 Bart writes: > On 25/04/2026 21:52, Tim Rentsch wrote: > >> Bart writes: >> >>>> [..questions about NULL == 0 ...] >>> >>> I expect that type matching would require both sides to be >>> pointers. Then the '0' is presumably converted to whatever pattern is >>> used for NULL. >>> >>> Although I always found it odd that, if P has a pointer type, then 'P >>> = 0' is fine, but not 'P = 42'. >> >> Do you also find it odd that 'P = 0' is fine, but 'P = 0.0' is not? > > No, because a RHS of 0.0, 1.0, 2.0, 3.7 ... are all treated consistently. > > But when the RHS is an integer, then of all the possible integer > values, 0 is a special case. If P is a variable having pointer type, what do you think these two statements are supposed to do? P = !1; P = !1.0; Notice that in both cases the value of the right hand side is an integer with a value of 0. >>> Also, suppose you did want to assign actual address 0x0000000 to P >>> using 'P = (T*)0'; what would happen here if NULL was non-zero? >> >> Assuming a declaration 'T *P;', do you really not know what >> happens for a statement 'P = (T*)0;'? > > Usually nothing happens, because a null pointer value and an address > of zero have the same bit-pattern. > > That's why I'm asking what happens when they don't: does it assume > this is assigning a NULL (which needs to be 0x80000000 say), or some > actual address of 0x00000000? It sounds like you're confusing a compile-time notion and a run-time notion. The symbol NULL is a compile-time construct, either simply 0 (or equivalent), or (void*)0 (or equivalent). Either expression, when evaluated at run-time, produces a bit pattern that is a null pointer. Note, a null pointer, not a NULL pointer. The identifier NULL is a purely compile-time notion, and is a noun, not an adjective. The word 'null' is an adjective modifying 'pointer', and indicates a run-time value that doesn't point anywhere (sometimes this is said as "not the same as a pointer to any object). Note also that null pointers don't have to all use the same bit pattern. On a 64-bit machine, an implementation could choose to designate any bit pattern where the top two bits are different as being a null pointer. Making this choice would have implications for how pointer values are compared, but just in terms of the bit-level representation it is workable, even if not especially practical.