search

browndeer / coprthr

The CO-PRocessing THReads (COPRTHR) SDK - latest release is v1.6.2 (Freewill)
http://www.browndeertechnology.com/coprthr.html
Other
94 stars 35 forks source link

reserved identifier violation #26

Open elfring opened 9 years ago

elfring commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

browndeer commented 9 years ago

I would appreciate if more identifiers can become standard-compliant

Reply to this email directly or view it on GitHub: https://github.com/browndeer/coprthr/issues/26#issuecomment-108319212

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.