The C Standard defines octal constants as a 0 followed by octal digits (0 1 2 3 4 5 6 7). Programming errors can occur when decimal values are mistakenly specified as octal constants.
Noncompliant Code Example
In this noncompliant code example, a decimal constant is mistakenly prefaced with zeros so that all the constants are a fixed length:
i_array = 2719; i_array = 4435; i_array = 0042;
Although it may appear that
i_array is assigned the decimal value 42, it is actually assigned the decimal value 34.
To avoid using wrong values and to make the code more readable, do not preface constants with zeroes if the value is meant to be decimal:
i_array = 2719; i_array = 4435; i_array = 42;
Misrepresenting decimal values as octal can lead to incorrect comparisons and assignments.
|Axivion Bauhaus Suite||7.2.0||CertC-DCL18|
|Helix QAC||2023.1||C0339, C1272|
|LDRA tool suite||9.7.1||83 S||Fully Implemented|
Octal and hexadecimal escape sequences shall be terminated
|Polyspace Bug Finder|
|CERT C: Rec. DCL18-C||Checks for use of octal constants (rec. fully covered)|
|SonarQube C/C++ Plugin|
|MISRA C:2012||Rule 7.1 (required)|
Victor, this looks like a good rule to work on. Comments:
I'm wondering how we can make this more enforceable. The NCE shows decimal constants and octal constants being assigned to different elements of an array. It would be easier to enforce that constraint. Also, we could insist that for any given variable, it can only be assigned and or compared to decimal or octal constants but not both. Opinions?
You're talking as if decimal and octoal ints were actually two different types. That is, conversions between one and the other should be explicit. Sounds like a good idea to me. C99 doesn't distinguish them, of course, but a SA tool could.
I think that would lead to large numbers of false positives. For example, it's not uncommon to define
INT_MAXto a decimal number (e.g.,
UINT_MAXto hexadecimal (e.g.,