reserved identifier violation

[elfring]

I would like to point out that identifiers like "__printcl_level" and "_VERSION_H" do eventually not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

[browndeer]

Thanks for the question, but no. You could submit same issue to Gnu libc
and any number of software packages implemented to provide lower-level
support for application development. Removing the underscores makes it
more likely, not less, that the symbols will conflict with application
code. If there is an instance of conflict with code underneath COPRTHR,
then we would adjust accordingly, and there is far less of a chance for
such conflict, and we can test for this namespace collision at build time.
Conversely, we cannot test for namespace conflict in a user's application
code when we build COPRTHR since this is a larger universe of code and
unknown. We interpret the admonition to apply to application code, not
run-time implementations like COPRTHR. There is an exception in the
standard that the "compiler" may use such symbols, yet there is no reason
to give compilers this special dispensation. We interpret this to include
run-time layers as well. If we are technically wrong in this position, we
are at least consistent with major code bases we all use each day, so that
takes away our concern, and we then do not agree with the logic of the
standard.

Again, thanks for the question though. Its a good one, and can create a
very nice debate.

-DAR

[elfring]

I would appreciate if more identifiers can become standard-compliant.

[browndeer]

I would appreciate if more identifiers can become
standard-compliant

---

Reply to this email directly or view it on GitHub:
#26 (comment)

Just curious, are you having trouble in C++ or C with some of the
identifiers? I think for C++ we should definitely put the symbols in a
namespace, but at the moment this has not been done. It has come up in
many discussions, but never elevated to a priority. That does not excuse
it not being done though.

-DAR

[elfring]

The programming languages "C" and "C++" specify requirements for fully conforming software applications. Are there chances for corresponding improvements?
How do you think about to avoid that this software depends on undefined behaviour?

[browndeer]

The programming languages "C" and "C++" specify requirements for fully
conforming software applications. Are there chances for corresponding
improvements?
How do you think about to avoid that this software depends on undefined
behaviour?

Just curious. Are you interested in using the code for a project that
requires a specific conformance via source code audit that requires
addressing this issue. If so, I understand and perhaps we can help.

Specifically to 106, can you provide and example where this is leading to
undefined behavior?

The logic of restricting certain symbols from the application developer is
to make them safely usable by the code supporting their application. If
this were not true, the restriction has no purpose. Limiting the use of
restricted symbols only to the compiler is a reflection of the naïve view
of how APIs would be developed to support applications at the time the
standard took shape. I assert the use of these symbols in COPRTHR, it is
not accidental, it is deliberate, the same as Gnu libc for example. In
fact, part of the run-time uses encoded symbols similar to type encoding
in C++ implementations. I would like to point out that following the
guidance in 106 in the internals of COPRTHR would make it LIKELY that the
application developer would find undefined behavior, thus I am reluctant
to make changes that would produce this effect. If that makes COPRTHR
non-conforming to C according to guidance that someone has come up with,
then it is in good company with many common packages that are used. I do
not consider it non-conforming based on the reservation of these symbols
for the "compiler" and what I know to be the history of this. Thus, I
have to see the problem before considering a solution.

Thanks.

-DAR

[elfring]

I would prefer that source files which do not belong to the implementation of a compiler for the programming language "C" (or "C++") will not tamper with the reserved name space.
Would you like to reconsider corresponding consequences?

[browndeer]

I would prefer that source files which do not belong to the implementation
of a compiler for the programming language "C" (or "C++") will not tamper
with the reserved name
space.
Would you like to reconsider corresponding consequences?

I am always glad to reconsider consequences, but could you explain what
they are in this case? I do not have a problem with using this name space
reserved for the "compiler" and if there was a concerted effort across
other packages to stop using it because there were consequences, I would
be more inclined to consider. If you look at the implementation for
malloc.c the conventions are not different from what we do. So this makes
me think I do not misread the situation, but perhaps I am wrong. I do
know there are consequences for not following the present choices for
symbols, so I am reluctant to solve an unknown problem of technicality for
an actual problem in use by application developers.

-DAR

[elfring]

Should your software only be used as a component of a compiler for the programming language "C" (or "C++")?

A few developers fixed some misnamed identifiers for other software projects already.