Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reserved identifier violation #38

Closed
elfring opened this issue Dec 6, 2022 · 7 comments
Closed

reserved identifier violation #38

elfring opened this issue Dec 6, 2022 · 7 comments

Comments

@elfring
Copy link

elfring commented Dec 6, 2022

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

@yanntm
Copy link
Member

yanntm commented Dec 11, 2022

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

This comment was marked as spam.

@yanntm
Copy link
Member

yanntm commented Dec 11, 2022

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
Copy link
Member

yanntm commented Dec 11, 2022

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.

cesaro/cunf#1

TAPAAL/verifytapn#23

greatspn/SOURCES#41

Tj-Cong/EnPAC_2021#1

asminer/smart#1

@elfring

This comment was marked as spam.

@elfring

This comment was marked as spam.

@yanntm
Copy link
Member

yanntm commented Dec 11, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants