Re: encapsulating directory operations

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.

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.