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: Official list of top C annoyances Date: Fri, 18 Sep 2026 08:29:51 -0700 Organization: A noiseless patient Spider Lines: 41 Message-ID: <86qziqtw5s.fsf@linuxsc.com> References: <117jqq0$2dd4g$1@dont-email.me> <117k28d$2gadn$1@dont-email.me> <117kfl3$2294f$1@dont-email.me> <117lpjb$31vr4$1@dont-email.me> <117m41r$35rim$1@dont-email.me> <117m6ca$35hat$1@dont-email.me> <117mc7o$38uh5$1@dont-email.me> <117meeo$35hat$2@dont-email.me> <117mlie$3co6q$1@dont-email.me> <117nf46$2294f$2@dont-email.me> <117od92$3ui33$1@dont-email.me> <117r3k7$3r5qo$4@dont-email.me> <117r5p8$s9ir$2@dont-email.me> <117r98e$3r5qn$6@dont-email.me> <117rk9n$s9ir$8@dont-email.me> <117v67i$2b9nt$1@dont-email.me> <20260914111759.911@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 18 Sep 2026 15:29:52 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1476949"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gy+udxukvJEYVtjbndc5MUFZr1CEYYFg="; posting-host="742ba13f59dd80260e7d5d77f8995b11" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:/hKR73f4mpicEJfmognw5FscoRk= sha1:HXH7w+Cqb1SM2tbQGTMaUyLNmpE= sha256:bziaTx+fmr8FV9U1f8wX7r9JGjbG/QB4w4DOC81/x18= sha1:BWNdxX7h8wySef3GnPPIhgOfR4k= sha256:hkBpp3ddXOGKGMVUSzRWGOxM9e6vYwV13/Cn476uPDM= Xref: csiph.com comp.lang.c:402235 Kaz Kylheku <046-301-5902@kylheku.com> writes: > On 2026-09-10, Chris M. Thomasson wrote: > >> On 9/9/2026 5:43 AM, David Brown wrote: >> [...] >> >>> Just defining the symbol is fine - for use as a pure header guard, >>> where the check is with "#ifndef" or "#ifdef", defining it to a >>> value has no added value. Adding the "1" in that example was done >>> without thinking. >> >> ________ >> #ifndef __NUMBER_GENERATOR_H__ >> #define __NUMBER_GENERATOR_H__ 1 >> ________ >> >> >> Is that __* non conformant? Does it breach the impl name prefix >> space? > > No matter what you name anything in C, you are playing roulette. > Vendor extensions and new standard features introduce identifiers > into namespaces that have not been hitherto reserved. > > It's like a traffic code. If you intrude into a namespace, it's > like running a stop sign. Nothing bad might happen, but if it > does, it is on you. > > However, C naming is like a residential neighborhood full of > unguarded intersections, with only a few stop signs. > > There isn't anything reasonable you can do to 100% ensure you will > never have a clash with anything in your C programming. (By > "reasonable", I do not intend to introduce moving goalposts: > specifically, I mean, not subjecting yourself to some horribly > inconvenient naming scheme in every single namespace which makes > it vanishingly improbable of ever seeing a clash). This picture is a lot more bleak than it needs to be. In practice dealing with possible naming conflicts is really not that hard.