Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Small challenge: sort names Date: Sun, 12 Apr 2026 16:15:46 -0700 Organization: None to speak of Lines: 63 Message-ID: <878qar3h3x.fsf@example.invalid> References: <10r4h6o$396qn$1@dont-email.me> <10r537m$in2o$4@dont-email.me> <10r5vh2$3mo17$2@dont-email.me> <10r64uq$3pf3r$1@dont-email.me> <20260409001030.000006c9@yahoo.com> <86h5pkww9a.fsf@linuxsc.com> <87cy0832zp.fsf@example.invalid> <86o6jo8f30.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sun, 12 Apr 2026 23:15:47 +0000 (UTC) Injection-Info: dont-email.me; posting-host="9f62fcc22bc30f56cb1f508c16f333f7"; logging-data="3040164"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+R2nam+PCRGwH3g6pp28Ep" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:XR8vJVf+uYX/4kJLLQXun1Ms5NM= sha1:XylNUUyAwTSd6suqQqMR3aOhkSs= Xref: csiph.com comp.lang.c:397514 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >> [...] >> >>> The semantics of !ptr has been codified to mean 1 for null pointers >>> since the original C standard. Heck, even during the 1970s when C >>> allowed assigning integers directly to pointers, K&R said that >>> assigning 0 to a pointer produces a pointer guaranteed to be >>> different than a pointer to any object. Any C implementation where >>> !ptr does the wrong thing should be avoided like the plague. >> >> Any C implementation where !ptr does the wrong thing almost certainly >> does not exist. It's difficult to imagine that a C compiler with >> such a fundamental bug would ever go out the door. > > My usual preference is to draw conclusions based on evidence rather > imagination or supposition. Good for you. >> It's barely possible that compiler that uses a representation other >> than all-bits-zero for null pointers might have such a bug, but >> (a) anyone creating such an implementation will almost certainly >> be extremely careful to get such things right, and (b) I'm not sure >> that any such compilers even exist, except perhaps for old systems >> that would be considered exotic today. > > Here again this sounds like just supposition. How much experience > do you have, and how extensive, using non-mainstream C compilers? > For myself I can't say I much at all, but I have seen one where > believe it or not assert() was implemented wrongly. assert()! I > certainly wouldn't have guessed that before actually seeing it. Quick summary: You wrote that "Any C implementation where !ptr does the wrong thing should be avoided like the plague." My response was, to summarize briefly, that such implementations are unlikely to exist and not worth worrying about. Do you disagree, or are you just criticizing the way I said it? I believe I was clear about the basis for my statement. No, I don't have a lot of experience with non-mainstream C compilers. I'm not going to perform a survey of all historical C implementations. Do you have anything useful to say about my point, as opposed to how I expressed it? I speculate that no released C implementation gets either !ptr or 2+2 wrong. A bug in the former is, I speculate, more likely than a bug in the latter, but neither seems likely. If such a bug exists, my guess is that it's in a pre-standard compiler for some system that is now obsolete. K&R1 (1978) is less than clear about the representation of null pointers. Would you be surprised to see a C compiler that handles !ptr incorrectly? I'd be interested in more information about the implementation that implemented assert() incorrectly. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */