Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: encapsulating directory operations Date: Tue, 10 Jun 2025 19:11:09 -0700 Organization: None to speak of Lines: 79 Message-ID: <87zfefgh8i.fsf@nosuchdomain.example.com> References: <100h650$23r5l$1@dont-email.me> <20250520065158.709@kylheku.com> <100i2la$292le$1@dont-email.me> <87a5770xjw.fsf@nosuchdomain.example.com> <100j09o$2f04b$1@dont-email.me> <87tt5ezx9y.fsf@nosuchdomain.example.com> <100j4t3$2foah$1@dont-email.me> <87ldqqzfj0.fsf@nosuchdomain.example.com> <100kak8$2q0s6$1@dont-email.me> <87a575zvmb.fsf@nosuchdomain.example.com> <100o3sc$3ll6t$1@dont-email.me> <87bjrkxonr.fsf@nosuchdomain.example.com> <87iklrtcys.fsf@nosuchdomain.example.com> <864ixavbs4.fsf@linuxsc.com> <87plfys9a5.fsf@nosuchdomain.example.com> <86bjqvr3u5.fsf@linuxsc.com> <878qlzibco.fsf@nosuchdomain.example.com> <20250610142356.296@kylheku.com> <874iwni6zb.fsf@nosuchdomain.example.com> <20250610180823.939@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Wed, 11 Jun 2025 04:11:11 +0200 (CEST) Injection-Info: dont-email.me; posting-host="97eb4bfbd108233324c46d773923fada"; logging-data="1700495"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/RTJOvtmNJdDVMn/oS1qJ1" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:qcRxDObkWPQZSF5TiwVAuVDV7DQ= sha1:59iTlgRiCqK+svRL6UsN7H3vejM= Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2025-06-10, Keith Thompson wrote: >> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>> On 2025-06-10, Keith Thompson wrote: >>>> I find the reservation of potential errno macro names annoying. >>> >>> If the standard contained /no/ statements about what a given header >>> file may reserve, then /any/ identifier whatsoever would be a potential >>> clash. >>> >>> The errno reservation is kind of good because implementors often extend >>> the set of errno constants. POSIX has a lot more of them than ISO C, and >>> there are some vendor-specific ones. >>> >>> Anyway, you can safely ignore the reservation theatre, and just >>> deal with clashes that happen, when they happen. (If you're lucky, >>> that could just be never). >> >> You can do that, but a new clash could happen when your code is >> compiled on a system that defines an errno macro that you haven't >> seen before. > > A new CRASH could happen too, and any number of things. Sure, but a compilation failure is more likely. > This clash would be literally one of the first roadblocks, if not the > first one, that we would see when just exploring the possibility whether > our code might not run on that system. > > At that point we could be months away from declaring that a supported > platform. Sure, but why not skip that first roadblock? >>> Anyway, ISO C, POSIX and vendors have historically introduced new >>> identifiers in spaces that were not previously declared as reserved. >>> If you're ever hit by that, you will feel like a completel sucker if >>> you've religiously adhered to namespaces from your end. >> >> Yes, that can happen, but no, I won't feel like a complete sucker. >> >> If I define my own strfoo() function and a new edition of the standard >> defines strfoo() in , the clash is my fault,and I could have >> avoided it by defining str_foo(). > > But, my point is, that maybe you could have called it kidneybeans() and > still have a clash. Certainly, I've already acknowledged that. But surely an identifier that the standard says is reserved is less likely to cause a clash than one that isn't. > In fact, if you are writing new string functions that are the same sort > of stuff like the standard ones, you should use the str prefix, > for consistency. > > If your code is influential enough, they might be standardized one > day---and then they are ready with the proper naming, so early adopters > of your functions won't have to change anything; just in their build > system drop the third party code and switch to what their library now > provides. I see your point, but ... meh. To me, a name matching "str[a-z]*" fairly strongly suggests a function declared in in ISO C. Of course it's not an absolute rule; see strlcpy(), for example (which is now part of POSIX). Even a str*() identifier that never clashes with ISO C's can still clash with POSIX, or glibc, or BSD, or .... I would have been happier if POSIX were less intrusive on the C standard library, but the way C and POSIX evolved didn't make that feasible. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */