Re: encapsulating directory operations

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 */