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

M5-0-12: Incorrect alerts on assignments of valid numerical values #541

Open
rvermeulen opened this issue Feb 21, 2024 · 1 comment
Open
Labels
Difficulty-Low A false positive or false negative report which is expected to take <1 day effort to address false positive/false negative An issue related to observed false positives or false negatives. Impact-Medium Standard-AUTOSAR

Comments

@rvermeulen
Copy link
Collaborator

rvermeulen commented Feb 21, 2024

Affected rules

  • cpp/autosar/signed-char-and-unsigned-char-type-shall-only-be-used-for-the-storage-and-use-of-numeric-values

Description

The implementation incorrectly implements the identification of numeric values.
Characters will have type char while numeric values will be promoted to int or unsigned int.
However, in the case of templates, the type of the numeric value will be the fully converted expressions type. That is, unsigned char in the example below.

Example

The following is compliant per example in the standard, however is still seen as a contravention.

template <typename T, T value>
class C1 {
  public:
    C1() : m_value(value) {}
  private:
    T m_value;
};

void fp_test() {
  C1<std::uint8_t, 10> l1;  // COMPLIANT[FALSE_POSITIVE]
  C1<std::uint8_t, 10U> l2; // COMPLIANT[FALSE_POSITIVE]
}
@rvermeulen rvermeulen added the false positive/false negative An issue related to observed false positives or false negatives. label Feb 21, 2024
@lcartey lcartey added Difficulty-Low A false positive or false negative report which is expected to take <1 day effort to address Impact-Medium labels Oct 18, 2024
@lcartey
Copy link
Collaborator

lcartey commented Jan 20, 2025

This query needs to be adjusted to report cases where a PlainCharType type is implicitly converted on assignment to a signed or unsigned char - note, it currently reports when a CharType is converted, which is incorrect because CharType includes the signed/unsigned types. e.g.:

  aexp.getExplicitlyConverted().getUnspecifiedType() instanceof PlainCharType

Note: this same confusion was made in M5-0-11, and will need to be fixed there as well.

If the char is explicitly converted, that is acceptable - the query needs to be updated to handle this case as well.

Finally, for results that only appear in instantiated templates we should consider reporting them separately, as they may only exists for a specific instantiation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Difficulty-Low A false positive or false negative report which is expected to take <1 day effort to address false positive/false negative An issue related to observed false positives or false negatives. Impact-Medium Standard-AUTOSAR
Projects
Development

No branches or pull requests

3 participants