pySCG: Modifying the description of CWE-197 so that it captures the CWE better

[openrefactorymunawar]

CWE-197 is about numeric truncation error (https://cwe.mitre.org/data/definitions/197.html).

The description of CWE-197 in the python secure coding guide section talks about predictable outcomes in loops by using int instead of float.

That is fine, we may want to narrow the scope of the CWE when we are creating a guideline. However, the examples that follow are not necessarily about loops.

Consider this example.

""" Non-compliant Code Example """
counter = 0.0
while counter <= 1.0:
    if counter == 0.8:
        print("we reached 0.8")  
        break  # never going to reach this
    counter += 0.1

Here the problem is in the if statement, not the loop.

In fact, the float issue may be in any equality case, even if it is not in a loop.

We need to update this description to either align more with numeric truncation (generalize the content) or keep the scope and make it more appropriate.

[myteron]

Hi @openrefactorymunawar, well spotted. The original name of the title was "Do not use float in counters". We had to restructure and rename all rules and made a mistake here, now its kind of a hybrid partially talking about two things.
It is apparently very hard or just odd to use a float as an actual counter in Python. Using range() forces int. I was neither able to come up with an example that uses a lambda that can successful break something.

There are more rules in the pipe that are related to truncation error's, rounding and precision.

• CWE-197: Control rounding when converting to less precise numbers
• CWE-681: Avoid an uncontrolled loss of precision when passing floating-point literals to a Decimal constructor
• CWE-681: Incorrect Conversion between Numeric Types
• CWE-1339: Insufficient Precision or Accuracy of a Real Number

Only one of them is on GitHub atm. Some of the content might be redundant. We have 2x197 and 2x681. Might be worth while to merge some of the stuff and break out the content that does not match.

[openrefactorymunawar]

For the floating point comparison, do you suggest that CWE-1339 is a more appropriate way to capture that? In that case, maybe a rule is created for CWE-1339 and another for CWE-681.