Re: encapsulating directory operations

On 6/10/2025 3:09 PM, Keith Thompson 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.
 

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().
 Nothing can prevent all possible name clashes, but I like to follow the
rules in the standard that let me prevent some of them.
 

Wrt to prepending to artificially create a namespace in C, ct, ala ct_*_*_* is fine with me. For your new addition how about a keith_thompson_*_*_* for your namespace? Or even a kt_* ? ;^)