Re: encapsulating directory operations

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Richard Harnden <richard.harnden@gmail.invalid> writes:

On 22/05/2025 23:32, Keith Thompson wrote:

[...]
>

In one of your library's headers:
extern const char ESCAPE;
In the corresponding *.c file:
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
Change the name if you prefer.

>
Wouldn't that be a reserved identifier?

>
Yes, it would.  Good catch.
>
(Identifiers starting with E followed by either a digit or an
uppercase letter are reserved;  they could be defined as macros
in <errno.h>.)

>
They are reserved only as macros, and only if <errno.h> has
been #include'd.
>
For this particular use, it's easy to make the definition work,
simply by adding
>
    #undef ESCAPE
>
before the declaration in the header file, and before the
definition in the source file (assuming of course that if
there are any #include <errno.h> they precede the #undef's).

>
It would be even easier to pick a different name.

>
The point of my comment was to help explain the rules about what
macro names are reserved and under what circumstances, not to
suggest a way to avoid conflicts.

And the point of my comment was to suggest a way to avoid conflicts.

A better way to avoid conflicts with E* macros is to take functions
where errno is needed, as for example signal(), and not call them
directly but rather wrap each one in a function, with the wrapping
functions put in (one or more) separate translation unit(s).  Those
translation units, and only those translation units, are the ones
where a #include <errno.h> is done.  Some details are needed to keep
the separation complete, but I think those aren't too hard to work
out, so if someone has trouble please ask.  This way most of the
program can use names beginning with E that might otherwise be
reserved, without any fear of conflicts.  There is a bit of source
code overhead, but that is paid only once, across all projects that
use this approach.  Also there are some other benefits, related to
libraries used that are not part of ISO C, such as Posix, which
again should be readily apparent to anyone used to working in large
projects that use such libraries.

That doesn't strike me as better.  You're suggesting a substantial
reorganization to avoid some simple name conflicts (identifiers
starting with 'E').  I find it much easier -- and yes, better --
to avoid defining identifiers starting with 'E'.  (Actually only
identifiers starting with 'E' followed by either a digit or an
uppercase letter are reserved.  It's simpler to avoid all identifiers
starting with 'E', but you can safely use something like "Escape"
if you like.)

If there are other reasons for such an organization, that's fine.

(My personal policy is to assume a more expansive set of reserved
identifiers, because it means I only have to remember a simpler
set of rules.  For example, I find it easier to avoid defining any
identifiers starting with '_' than to account for the rules for which
_* identifiers are reserved for which purposes in which contexts.
Of course I'll look up and apply the actual rules when I need to.)

I find the reservation of potential errno macro names annoying.
Using and reserving identifiers starting with "E_", for example,
would have been less intrusive.  But we're stuck with it.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */