reserved identifier violation

[elfring]

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

[klihub]

Hi,

To be honest, I do not see a compelling enough reason to do so at the
moment. Such a commit would practically need to touch files all over the
place in the source tree (practically all headers). This is something we
generally try to avoid. Of course we could split it to one commit per
logical entity within the source tree. But my real problem with doing this
is that I do not see a single tangible benefit that such commit/commits
would bring. Maybe I'm wrong, please feel free to correct me if I'm missing
something obvious here.

Don't get me wrong, I understand/admit that if we interpreted the C++
standard pedantically (and cared a lot about C++ in the first place) then
you're absolutely right. But then similarly, we should not violate the
recommendations for naming conventions put forward by the original C
standard either. We should not suffix our typedefs with _t, because those
are, in principle, reserved for the standard libraries. Neither should we
prefix any of our globally visible/exported symbols by _, or __ because
those are also reserved for the standard libraries.

However we chose not to do so but, just like a significant majority of the
other C-based projects out there, we decided to instead pretend that we are
a 'standard' library and additionally chose to do 'namespacing' the C way
to avoid/minimize the probability of naming/symbol clashes. IOW, we

1. did our best to choose a unique name for our project
2. came up with a full and a shorthand prefix based on the chosen name
3. prefix all our macros (including the standard header #ifdef wrapper
   boilerplates) and global symbols with one of the prefixes (after any
   potential leading _)

This is merely a personal choice/preference of the team that originally
bootstrapped Murphy. We simply find it to be a more flexible and reasonable
convention than blindly following the standard recommendations to the dot.
We tried to be fairly strict and consistent with our choices. I'm sure we
failed to do so in a few places, and I'm more than willing to fix those
inconsistencies if/when they are discovered.

Cheers,
Krisztian

On Mon, Sep 7, 2015 at 2:43 PM, Markus Elfring [email protected]
wrote:

I would like to point out that identifiers like "MURPHY_CORE_H
https://github.com/01org/murphy/blob/5e4215ff7c97bb9c557687f288efe5154795c95d/src/core.h#L30"
and "MDB_COND_H
https://github.com/01org/murphy/blob/9ffaed4e490149045e34f55a2bf1f9bc3531ad29/src/murphy-db/mdb/cond.h#L30"
do not fit
https://www.securecoding.cert.org/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier#DCL51-CPP.Donotdeclareordefineareservedidentifier-NoncompliantCodeExample%28HeaderGuard%29
to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

—
Reply to this email directly or view it on GitHub
#14.

[elfring]

How do you think about to avoid that this software depends on undefined behaviour?

[klihub]

Hi,

I already told you in my previous reply how I think about it. I also told
you how our naming convention rules are designed to mitigate the danger and
eliminate the risk of undefined behavior in practice. The murphy-db
inconsistency of not having the #ifdef-wrappers prefixed with __MURPHY we
should probably fix though...

Cheers,
Krisztian

On Fri, Sep 11, 2015 at 9:23 PM, Markus Elfring [email protected]
wrote:

How do you think about to avoid that this software depends on undefined
behaviour
https://www.securecoding.cert.org/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_106
?

—
Reply to this email directly or view it on GitHub
#14 (comment).

[elfring]

I would appreciate if your software will become completely standard-compliant.