Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
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>
	<b7fb8fc41d43807641e673e1ca1d3baf69f5766f@i2pn2.org>
	<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 <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>> On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> 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 <string.h>, 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 <string.h> 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 <string.h>
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 */