From Newsgroup: comp.lang.c

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

"Paul Edwards" <mutazilah@gmail.com> writes:

[...]

And C90 (etc) could potentially be extended to include a folder.h

C90 will never be extended.

The C90 edition of the ISO C standard will never be changed by
ISO. The C90 language could be extended by some independent
party.

It was made obsolete by C99, which was made obsolete by C11,
which was made obsolete by C23. [...]

No, they aren't, and no, they weren't. C90, both the language
and the document that defines it, are not obsolete, but still in
use. The same applies to C99 and C11.

The ISO C standard doesn't say anything about making earlier
editions obsolete. The language used in the ISO C standard is
that each edition cancels and replaces the previous edition as
being the current ISO C standard. At any one time there is only
one ISO C standard. But changing which edition corresponds to
the current ISO standard doesn't change the status of the earlier
documents, or of the language they describe. And in particular,
because they are all still in use, they are not obsolete.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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:

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.

Yes, and thereby missing the point of my comment.

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 disagree with your characterization. In practice organizing
code along the lines I suggested carries little overhead and also
yields some other benefits that serve to raise the confidence in
the code body as a whole.

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.)

Locally easier. Globally costly. Separating out constructs that
are used only rarely, such as errno and error names, scales better,
because whole swaths of code can be read and written without having
to worry about the exceptional cases, which leaves the mind free to
focus on more important matters.

Keep in mind that I have tried it both ways. I'm guessing that you
haven't.

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.

We are stuck with having identifiers starting with E being reserved
if <errno.h> is included. We are /not/ stuck with being forced to
deal with the consequences of that rule everywhere in a code base
just because there are a few library calls that need to test errno.
--- Synchronet 3.21b-Linux NewsLink 1.2