reserved identifier violation

[elfring]

I would like to point out that identifiers like “_GDDD” and “_GHom” do eventually not fit to the expected naming convention of the C++ language standard. Would you like to adjust your selection for unique names?

[yanntm]

Sorry but treating "issues" is time consuming, and issues are not a place to interact with bots, but with actual users or developers of the software. I have my own code quality analysis tools, thank you. This behavior has been reported asking for a ban of this user.

[elfring]

I have my own code quality analysis tools, thank you.

:thinking: It seems that we stumble on a temporary disagreement about implementation details.

:thought_balloon: I suggest to avoid that software components depend on undefined behaviour.

[yanntm]

Right, if my formal verification tool exhibits UB or some other non deterministic behavior, please do report that, as a user.

But this code base is stable, and rigorously tested at the functional level (e.g. winning formal verification competitions), so it seems extremely doubtful that any such behavior exists.

• it does not even target C++ standard since we use gcc specific features in it anyway. So if the symbol does not clash with anything in gcc, I'm happy.

If it did, I would already know about it, it would most probably create probably severe compilation errors, the _prefix naming of storage classes w.r.t. to containers is used through the code base. If UB existed w/o compilation errors the functional tests would exhibit it.

So we are back to simply an issue submitted by an automated code quality tool (basically a bot), not a user reporting an actual issue with the software.

A repo with a lot of pending issues just looks bad, so I certainly do not want bots (other than my own) creating issues or PR, esp. if they are in fact irrelevant like this one. Just answering this pointless issue that you don't even care about is taking my time.

So the point remains, issues are not for interacting with automated code quality analysis tools, which are only indicative anyway in the best case.

So, please refrain from (mis)using this communication vector to pander whatever code quality analysis improvement you're trying to sell, it's bad etiquette.

[yanntm]

I'll link a few of my colleagues here so I can share my thoughts with them as the numerous issues submitted all concern MCC related tools. so these are all people I know.

https://github.com/cesaro/cunf/issues/1

https://github.com/TAPAAL/verifytapn/issues/23

https://github.com/greatspn/SOURCES/issues/41

https://github.com/Tj-Cong/EnPAC_2021/issues/1

https://github.com/asminer/smart/issues/1

[elfring]

…, so it seems extremely doubtful that any such behavior exists.

:thought_balloon: Undefined behaviour exists as known rules from the standard specification of the programming language “C++” get violated.

it does not even target C++ standard since we use gcc specific features in it anyway.

:thought_balloon: I recommend to reconsider also this view.

So if the symbol does not clash with anything in gcc, I'm happy.

:thinking: I find such a software development approach questionable.

…, not a user reporting an actual issue with the software.

I am a special user who dared to present another bug report.

[elfring]

so these are all people I know.

:thought_balloon: Several developers and code reviewers are aware that some programmers repeat known weaknesses and mistakes (in various software components).

[yanntm]

GH team advises simply moderating the offending user so I'll do that.