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

(C/C++) "<<=" has the wrong methodFullName? #1348

Closed
NemoTR opened this issue May 4, 2022 · 3 comments
Closed

(C/C++) "<<=" has the wrong methodFullName? #1348

NemoTR opened this issue May 4, 2022 · 3 comments

Comments

@NemoTR
Copy link

NemoTR commented May 4, 2022

  "50": {
    "name": "<operators>.assignmentShiftLeft",
    "signature": "",
    "code": "c <<= 1",
    "typeFullName": "<empty>",
    "columnNumber": 5,
    "order": 12,
    "methodFullName": "<operators>.assignmentShiftLeft",
    "_label": "CALL",
    "argumentIndex": -1,
    "dynamicTypeHintFullName": [],
    "dispatchType": "STATIC_DISPATCH",
    "lineNumber": 9,
    "id": 50,
    "inpdg": true,
    "callto": "EXTN"
  },

Why the methodFullName of <<= is '<operators>.assignmentShiftLeft' while others' methodFullName is '<operator>.xxx'?
Is this a little mistake?

@NemoTR
Copy link
Author

NemoTR commented May 4, 2022

I also found that >>= had the methodFullName "<operators>.assignmentArithmeticShiftRight".

  "53": {
    "name": "<operators>.assignmentArithmeticShiftRight",
    "signature": "",
    "code": "c >>= 1",
    "typeFullName": "<empty>",
    "columnNumber": 5,
    "order": 13,
    "methodFullName": "<operators>.assignmentArithmeticShiftRight",
    "_label": "CALL",
    "argumentIndex": -1,
    "dynamicTypeHintFullName": [],
    "dispatchType": "STATIC_DISPATCH",
    "lineNumber": 10,
    "id": 53,
    "inpdg": true,
    "callto": "EXTN"
  },

Maybe this is intended?

@max-leuthaeuser
Copy link
Contributor

Thanks for reporting this. Its clearly a typo. We'll fix that.

@mpollmeier
Copy link
Contributor

This is indeed a little mistake/typo, but unfortunately fixing these constants would be a backwards incompatible change. There are situations where we introduce breaking changes, but I don't think fixing some typos is a strong enough mandate.

For now we'll just add a TODO, and can make the change next time there's a breaking change:
ShiftLeftSecurity/codepropertygraph#1630

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

3 participants