SONARJAVA-7151: S1314: Ignore short octal literals and common permission patterns

[romainbrenguier]

Summary

• S1314 (OctalValuesCheck) no longer reports octal int literals of length <= 2 (e.g. 00, 02, 07), whose value is identical in decimal.
• It also no longer reports common Unix permission modes (e.g. 0644, 0755, 0777, 04755, 01777): an optional special-bits digit followed by owner/group/others digits, where owner has at least read permission and each digit is one of 0, 4, 5, 6, 7.
• It no longer reports octal literals written with the explicit 0_ prefix (e.g. 0_7, 0_13, 0_755), and the issue message now suggests this prefix when an octal value is intended.
• Added compliant and noncompliant samples covering these cases.

🤖 Generated with Claude Code

Agent workflow

Tool link: https://github.com/SonarSource/languages-experimental-tooling/tree/romain/my-tickets/personal/romain-brenguier
PR created using uv run create_with_claude.py Rule S1314, should not throw for int literals that have length <= 2 (e.g. 02), it should also not throw for common permission patterns like 0755 etc... Add samples to the tests for these cases

PR updated using uv run update_with_claude.py --prompt "Implement the action plan described in the document We should allow pattern like 0_7 0_13 0_755 (using prefix 0_) to write octal values as this is more explicit than without the _. Make that explicit in the issue message, that a possible fix if octal is really intended 0_ can be used as it is more explicit. We should still allow common permission patterns like 0755 and 0_755. Don't make change to the html directly but comment on the PR what should be the change to the rspec.." -a "We should allow pattern like 0_7 0_13 0_755 (using prefix 0_) to write octal values as this is more explicit than without the _. Make that explicit in the issue message, that a possible fix if octal is really intended 0_ can be used as it is more explicit. We should still allow common permission patterns like 0755 and 0_755. Don't make change to the html directly but comment on the PR what should be the change to the rspec." -g "claude"

PR updated using uv run update_with_claude.py --prompt "Implement the action plan described in the document Change the implementation to no longer exclude permission patterns from raising. Instead for these cases suggest to use a String equivalent to represent permissions where possible for instance "rwxrwxrwx" instead of 0777.." -a "Change the implementation to no longer exclude permission patterns from raising. Instead for these cases suggest to use a String equivalent to represent permissions where possible for instance "rwxrwxrwx" instead of 0777." -g "claude"

PR updated using uv run update_with_claude.py --prompt "Implement the action plan described in the document Code Review: Updates S1314 for Java by adding it to the Sonar way profile, rewriting the description, and documenting exceptions for short literals, Unix permission modes, and 0_-prefixed octal literals. Changes are requested before merge. Open issues: the 0755` example is still listed as confusing in the Why section, the permission-mode exception lacks a defined criterion, the worked octal alternative keeps the bug the noncompliant comments describe, the intro and list use parentheses the style guide avoids, the PR title does not follow the rule-change convention, and the PR description no longer matches the How to fix guidance. The sonar-java OctalValuesCheck does not yet implement these exceptions, so the spec must ship with the check change and the PR should stay in draft until then.

1. 💡 Quality: New Java description uses parentheses the style guide says to avoid
   Files: rules/S1314/java/rule.adoc:1, rules/S1314/java/rule.adoc:9-11

   The style guide says parentheses should be avoided and the information should be worked into the sentence instead. The new intro sentence uses three parentheticals: "(e.g., 010, 0755)", "(base-8)" and "(base-10)". Each item in the worked-example list also puts its calculation in parentheses, for example "(1×8 + 0 = 8)". Please rephrase, for example: "...starts with a zero followed by other digits, such as 010 or 0755. Java interprets these as base-8 octal values rather than base-10 decimal values."

   Fix (Rewrite the intro sentence without parentheses.):
   This rule raises an issue when an integer literal starts with a zero followed by other digits, such as 010 or 0755. Java interprets such a literal as a base-8 octal value rather than a base-10 decimal value.

2. 💡 Quality: Why-section still uses exempted 0755 as an example of confusing octal
   Files: rules/S1314/java/rule.adoc:11, rules/S1314/java/rule.adoc:22, rules/S1314/java/rule.adoc:29

   This commit makes 0755 compliant: line 22 calls it the conventional Unix permission notation and line 29 marks it // Compliant. Line 11, in "Why is this an issue?", still lists 0755 next to 010 and 060 as an example of a confusing octal literal. The rule now presents the same literal as both a problem and an accepted exception. Replace it with a literal the rule still flags, such as 01000, which matches the updated noncompliant example on line 52.

   Fix (Use a literal that is still noncompliant as the worked example.):

   • 01000 represents 512 in decimal (1×512 + 0 + 0 + 0 = 512)

3. 💡 Quality: PR title doesn't follow the rule-change title convention
   Files: rules/S1314/java/rule.adoc:1

   The repo requires rule change PR titles in the form <JIRA-TICKET-ID> Modify rule Sxxxx. This PR is titled SONARJAVA-7151: Update S1314: add to Sonar way, ..., which has an extra colon and uses Update instead of Modify rule. Rename it to something like SONARJAVA-7151 Modify rule S1314: Add to Sonar way and document exceptions.

4. ⚠️ Edge Case: "Common Unix file permission modes" leaves the exemption undefined
   Files: rules/S1314/java/rule.adoc:22, rules/S1314/java/rule.adoc:29-33, rules/S1314/java/rule.adoc:10, rules/S1314/java/rule.adoc:54

   The new exception replaces a checkable criterion with "Common Unix file permission modes", but it never says which literals count. That leaves readers unable to decide whether an issue applies. The page's own examples show the gap. 060 (group read/write) and 010 (group execute) are valid permission modes, yet lines 10, 39 and 54 treat them as noncompliant. Meanwhile 0700 and 04755 are exempt. A developer looking at 0640, 0060 or 02775 cannot tell whether the rule should flag it. State the actual criterion the analyzer uses, such as an explicit list of modes or a shape like a 4-5 character literal whose digits form a valid mode, and explain why 060 stays noncompliant.

   Fix (Spell out the exact set or shape of exempt permission literals.):

   • Literals that match a Unix file permission mode written with four or five characters, such as 0644, 0755 or 04755, where the octal interpretation is intended. Shorter literals such as 060 are still reported.

5. 💡 Quality: Octal alternative keeps the bug the noncompliant comments describe
   Files: rules/S1314/java/rule.adoc:53-55, rules/S1314/java/rule.adoc:67-74

   The noncompliant comments say these variables were meant to hold 10, 60 and 1000, for example "timeout holds 48, not 60". The new "Or, if octal is intended" block then rewrites the same variables as 0_10, 0_60 and 0_1000. Those still evaluate to 8, 48 and 512. Readers may take this as permission to add 0_ just to silence the rule, which leaves the timeout bug from the impact section in place. Use a separate example where octal is clearly intended, such as a permission mode like int mode = 0_640;.

   Fix (Show the 0_ form on a value whose octal meaning is intended.):
   Or, if an octal value is intended, such as a file permission mode:

   [source,java]

   int mode = 0_640;

6. 💡 Quality: PR description no longer matches the How to fix guidance
   Files: rules/S1314/java/rule.adoc:45, rules/S1314/java/message.adoc:3

   The PR description says the "How to fix it" section mentions the 0x/0b prefixes. It also says nothing about the new 0_-prefix exception or the Java-specific message. This commit replaced the fix sentence with decimal and 0_ guidance, so the 0x/0b mention now only appears in the Why section. It also added java/message.adoc. Update the PR description so reviewers judge the rule against what it now says.." -a "Code Review: Updates S1314 for Java by adding it to the Sonar way profile, rewriting the description, and documenting exceptions for short literals, Unix permission modes, and 0_-prefixed octal literals. Changes are requested before merge. Open issues: the 0755 example is still listed as confusing in the Why section, the permission-mode exception lacks a defined criterion, the worked octal alternative keeps the bug the noncompliant comments describe, the intro and list use parentheses the style guide avoids, the PR title does not follow the rule-change convention, and the PR description no longer matches the How to fix guidance. The sonar-java OctalValuesCheck does not yet implement these exceptions, so the spec must ship with the check change and the PR should stay in draft until then.

7. 💡 Quality: New Java description uses parentheses the style guide says to avoid
   Files: rules/S1314/java/rule.adoc:1, rules/S1314/java/rule.adoc:9-11

   The style guide says parentheses should be avoided and the information should be worked into the sentence instead. The new intro sentence uses three parentheticals: "(e.g., 010, 0755)", "(base-8)" and "(base-10)". Each item in the worked-example list also puts its calculation in parentheses, for example "(1×8 + 0 = 8)". Please rephrase, for example: "...starts with a zero followed by other digits, such as 010 or 0755. Java interprets these as base-8 octal values rather than base-10 decimal values."

   Fix (Rewrite the intro sentence without parentheses.):
   This rule raises an issue when an integer literal starts with a zero followed by other digits, such as 010 or 0755. Java interprets such a literal as a base-8 octal value rather than a base-10 decimal value.

8. 💡 Quality: Why-section still uses exempted 0755 as an example of confusing octal
   Files: rules/S1314/java/rule.adoc:11, rules/S1314/java/rule.adoc:22, rules/S1314/java/rule.adoc:29

   This commit makes 0755 compliant: line 22 calls it the conventional Unix permission notation and line 29 marks it // Compliant. Line 11, in "Why is this an issue?", still lists 0755 next to 010 and 060 as an example of a confusing octal literal. The rule now presents the same literal as both a problem and an accepted exception. Replace it with a literal the rule still flags, such as 01000, which matches the updated noncompliant example on line 52.

   Fix (Use a literal that is still noncompliant as the worked example.):

   • 01000 represents 512 in decimal (1×512 + 0 + 0 + 0 = 512)

9. 💡 Quality: PR title doesn't follow the rule-change title convention
   Files: rules/S1314/java/rule.adoc:1

   The repo requires rule change PR titles in the form <JIRA-TICKET-ID> Modify rule Sxxxx. This PR is titled SONARJAVA-7151: Update S1314: add to Sonar way, ..., which has an extra colon and uses Update instead of Modify rule. Rename it to something like SONARJAVA-7151 Modify rule S1314: Add to Sonar way and document exceptions.

10. ⚠️ Edge Case: "Common Unix file permission modes" leaves the exemption undefined
    Files: rules/S1314/java/rule.adoc:22, rules/S1314/java/rule.adoc:29-33, rules/S1314/java/rule.adoc:10, rules/S1314/java/rule.adoc:54

    The new exception replaces a checkable criterion with "Common Unix file permission modes", but it never says which literals count. That leaves readers unable to decide whether an issue applies. The page's own examples show the gap. 060 (group read/write) and 010 (group execute) are valid permission modes, yet lines 10, 39 and 54 treat them as noncompliant. Meanwhile 0700 and 04755 are exempt. A developer looking at 0640, 0060 or 02775 cannot tell whether the rule should flag it. State the actual criterion the analyzer uses, such as an explicit list of modes or a shape like a 4-5 character literal whose digits form a valid mode, and explain why 060 stays noncompliant.

    Fix (Spell out the exact set or shape of exempt permission literals.):

    • Literals that match a Unix file permission mode written with four or five characters, such as 0644, 0755 or 04755, where the octal interpretation is intended. Shorter literals such as 060 are still reported.

11. 💡 Quality: Octal alternative keeps the bug the noncompliant comments describe
    Files: rules/S1314/java/rule.adoc:53-55, rules/S1314/java/rule.adoc:67-74

    The noncompliant comments say these variables were meant to hold 10, 60 and 1000, for example "timeout holds 48, not 60". The new "Or, if octal is intended" block then rewrites the same variables as 0_10, 0_60 and 0_1000. Those still evaluate to 8, 48 and 512. Readers may take this as permission to add 0_ just to silence the rule, which leaves the timeout bug from the impact section in place. Use a separate example where octal is clearly intended, such as a permission mode like int mode = 0_640;.

    Fix (Show the 0_ form on a value whose octal meaning is intended.):
    Or, if an octal value is intended, such as a file permission mode:

    [source,java]

    int mode = 0_640;

12. 💡 Quality: PR description no longer matches the How to fix guidance
    Files: rules/S1314/java/rule.adoc:45, rules/S1314/java/message.adoc:3

    The PR description says the "How to fix it" section mentions the 0x/0b prefixes. It also says nothing about the new 0_-prefix exception or the Java-specific message. This commit replaced the fix sentence with decimal and 0_ guidance, so the 0x/0b mention now only appears in the Why section. It also added java/message.adoc. Update the PR description so reviewers judge the rule against what it now says." -g "claude"`

PR updated using uv run update_with_claude.py --prompt "Implement the action plan described in the document [MINOR] Split this 185 characters long line (which is greater than 180 authorized). (component: java-checks/src/main/java/org/sonar/java/checks/OctalValuesCheck.java, line: 54)." -a "[MINOR] Split this 185 characters long line (which is greater than 180 authorized). (component: java-checks/src/main/java/org/sonar/java/checks/OctalValuesCheck.java, line: 54)" -g "claude"

PR updated using uv run update_with_claude.py --prompt "Implement the action plan described in the document Code Review: Rewrites the Java S1314 spec to add the rule to Sonar way, with new exceptions for literals of at most two characters, 0_-prefixed literals, and Unix permission modes, plus a dedicated permission-mode message. Changes are requested before merge: the PR title doesn't follow the rule-change convention, the description is out of sync with the How to fix guidance, and the permission-mode message omits the decimal fix for zero-padded decimals like 0700. The spec also must not ship until sonar-java's OctalValuesCheckimplements the same exceptions and message, sinceisOctalstill flags00, 07, and 0_13` and the check's tests contradict the new spec.

1. 💡 Quality: PR title doesn't follow the rule-change title convention
   Files: rules/S1314/java/rule.adoc:1

   The repo requires rule change PR titles in the form <JIRA-TICKET-ID> Modify rule Sxxxx. This PR is titled SONARJAVA-7151: Update S1314: add to Sonar way, ..., which has an extra colon and uses Update instead of Modify rule. Rename it to something like SONARJAVA-7151 Modify rule S1314: Add to Sonar way and document exceptions.

2. 💡 Quality: PR description no longer matches the How to fix guidance
   Files: rules/S1314/java/rule.adoc:45, rules/S1314/java/message.adoc:3

   The PR description says the "How to fix it" section mentions the 0x/0b prefixes. It also says nothing about the new 0_-prefix exception or the Java-specific message. This commit replaced the fix sentence with decimal and 0_ guidance, so the 0x/0b mention now only appears in the Why section. It also added java/message.adoc. Update the PR description so reviewers judge the rule against what it now says.

3. 💡 Edge Case: Permission-mode message drops the decimal fix for padded decimals
   Files: rules/S1314/java/message.adoc:4, rules/S1314/java/rule.adoc:17

   Line 17 says the dedicated message fires for any four-character literal whose three digits are each 0, 4, 5, 6 or 7, with an owner digit of at least 4. That pattern also covers zero-padded decimals, which are the main bug this rule targets. Examples are times of day like int start = 0700; or 0645, and counts like 0500. For those, the message in message.adoc:4 only offers a symbolic permission string such as "rwx------" or the 0_ prefix. It never mentions the decimal value the developer probably meant, so they get pointed at a fix that makes no sense. Add the decimal alternative to the permission-mode message, for example: "If this is a file permission mode, use the symbolic permission string "{symbolic}"; otherwise use the decimal value. If an octal value is intended, use the more explicit "0_" prefix."

4. The Validate Rules job failed because the S1314 Java AsciiDoc description uses inline code ending in an underscore (0_), which the asciidoc validator rejects; this is directly caused by the PR's documentation change.." -a "Code Review: Rewrites the Java S1314 spec to add the rule to Sonar way, with new exceptions for literals of at most two characters, 0_-prefixed literals, and Unix permission modes, plus a dedicated permission-mode message. Changes are requested before merge: the PR title doesn't follow the rule-change convention, the description is out of sync with the How to fix guidance, and the permission-mode message omits the decimal fix for zero-padded decimals like 0700. The spec also must not ship until sonar-java's OctalValuesCheck implements the same exceptions and message, since isOctal still flags 00, 07, and 0_13 and the check's tests contradict the new spec.

5. 💡 Quality: PR title doesn't follow the rule-change title convention
   Files: rules/S1314/java/rule.adoc:1

   The repo requires rule change PR titles in the form <JIRA-TICKET-ID> Modify rule Sxxxx. This PR is titled SONARJAVA-7151: Update S1314: add to Sonar way, ..., which has an extra colon and uses Update instead of Modify rule. Rename it to something like SONARJAVA-7151 Modify rule S1314: Add to Sonar way and document exceptions.

6. 💡 Quality: PR description no longer matches the How to fix guidance
   Files: rules/S1314/java/rule.adoc:45, rules/S1314/java/message.adoc:3

   The PR description says the "How to fix it" section mentions the 0x/0b prefixes. It also says nothing about the new 0_-prefix exception or the Java-specific message. This commit replaced the fix sentence with decimal and 0_ guidance, so the 0x/0b mention now only appears in the Why section. It also added java/message.adoc. Update the PR description so reviewers judge the rule against what it now says.

7. 💡 Edge Case: Permission-mode message drops the decimal fix for padded decimals
   Files: rules/S1314/java/message.adoc:4, rules/S1314/java/rule.adoc:17

   Line 17 says the dedicated message fires for any four-character literal whose three digits are each 0, 4, 5, 6 or 7, with an owner digit of at least 4. That pattern also covers zero-padded decimals, which are the main bug this rule targets. Examples are times of day like int start = 0700; or 0645, and counts like 0500. For those, the message in message.adoc:4 only offers a symbolic permission string such as "rwx------" or the 0_ prefix. It never mentions the decimal value the developer probably meant, so they get pointed at a fix that makes no sense. Add the decimal alternative to the permission-mode message, for example: "If this is a file permission mode, use the symbolic permission string "{symbolic}"; otherwise use the decimal value. If an octal value is intended, use the more explicit "0_" prefix."

8. The Validate Rules job failed because the S1314 Java AsciiDoc description uses inline code ending in an underscore (0_), which the asciidoc validator rejects; this is directly caused by the PR's documentation change." -g "claude"`

PR updated using uv run update_with_claude.py --prompt "Implement the action plan described in the document Can you pull using rule-api the changes to the rspec for S1314 from the pull request https://github.com/SonarSource/rspec/pull/8334? And Rename OctalValuesCheck sample file to something ending in Sample." -a "Can you pull using rule-api the changes to the rspec for S1314 from the pull request https://github.com/SonarSource/rspec/pull/8334? And Rename OctalValuesCheck sample file to something ending in Sample" -g "claude"

---

Summary by Gitar

• Permission-mode message:
  • Suggests a symbolic permission string such as rwxr-xr-x for four-character permission literals like 0755
• Rule metadata:
  • Adds S1314 to the Sonar way profile and rewrites the RSPEC description with the new exceptions

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-7151

[romainbrenguier]

Suggested RSPEC change for S1314 (not applied to the generated HTML in this PR)

The implementation now:

• ignores octal literals of length <= 2 (00..07),
• ignores common Unix permission modes (0644, 0755, 04755, ...),
• ignores literals using the explicit 0_ prefix (0_7, 0_13, 0_755),
• reports with the message: Use decimal values instead of octal ones. If an octal value is intended, use the more explicit "0_" prefix.

Proposed update to the rule description in RSPEC:

<h2>Why is this an issue?</h2>
<p>Integer literals starting with a zero are octal rather than decimal values. While using octal values is fully supported, most developers do not
have experience with them. They may not recognize octal values as such, mistaking them instead for decimal values.</p>
<p>This rule does not raise issues on:</p>
<ul>
  <li>single-digit octal literals such as <code>00</code> or <code>07</code>, whose value is the same in decimal,</li>
  <li>common Unix file permission modes such as <code>0644</code>, <code>0755</code> or <code>04755</code>,</li>
  <li>octal literals written with the <code>0_</code> prefix, such as <code>0_13</code>, which makes the intent explicit.</li>
</ul>
<h2>How to fix it</h2>
<p>Use the decimal value instead. If an octal value is really intended, use the <code>0_</code> prefix, which makes it clear to readers
that the literal is octal.</p>
<h3>Noncompliant code example</h3>
<pre>
int myNumber = 010; // Noncompliant. myNumber will hold 8, not 10 - was this really expected?
</pre>
<h3>Compliant solution</h3>
<pre>
int myNumber = 8;
</pre>
<p>or, if octal is intended:</p>
<pre>
int myNumber = 0_10;
</pre>
<h2>Resources</h2>
<!-- unchanged -->

The issue message in RSPEC metadata (if documented) should become: Use decimal values instead of octal ones. If an octal value is intended, use the more explicit "0_" prefix.

[rombirli]

/pvf

[rombirli]

LGTM but i would expect rspec changes about "0_" prefix exclusion pulled into this PR
Also rspec change about sonar-way, and a pvf run before merging 🙏

[rombirli]

NIT: I know this file existed before you touched to this rule, but in general we prefer to suffix reproducer files with "Sample", this PR could be a good opportunity to rename it

[hashicorp-vault-sonar-prod]

⚠️ Performance Validation finished without publishing a dashboard. See run logs.

[rombirli]

/pvf

[hashicorp-vault-sonar-prod]

⚠️ Performance Validation finished without publishing a dashboard. See run logs.

[gitar-bot]

Code Review ✅ Approved 2 closed / 2 findings

🟡 Medium risk · Adding S1314 to Sonar way and changing its octal detection and messages could alter issue reports and suggested fixes across Java projects.

Refines S1314 (OctalValuesCheck) to skip short octal literals, common Unix permission modes, and 0_-prefixed octal literals, with the issue message suggesting 0_ when octal is intended. Underscore-separated octal literals that previously bypassed the new exemptions are now handled, and the PR description has been updated to match. No open issues remain.

✅ 2 closed

✅ Edge Case: Underscore-separated octal literals bypass the new exemptions

📄 java-checks/src/main/java/org/sonar/java/checks/OctalValuesCheck.java:47-48 📄 java-checks/src/main/java/org/sonar/java/checks/OctalValuesCheck.java:57-59
Both new exemptions check the raw token text from tree.value(). Java allows underscores in octal literals, so 0_7 (value 7, same as 07) has length 3 and passes the value.length() > 2 check. A permission written as 0_755 also fails PERMISSION_PATTERN and still gets reported. Fix: strip underscores before both checks, e.g. String digits = value.replace("_", "");, and run the length check and isPermission on digits.

✅ Quality: PR description still says permission modes are no longer reported

📄 java-checks/src/main/java/org/sonar/java/checks/OctalValuesCheck.java:50-57 📄 java-checks/src/test/files/checks/OctalValuesCheck.java:22-36
The PR summary still says S1314 "no longer reports common Unix permission modes (e.g. 0644, 0755, 0777, 04755, 01777)". This commit changes that. visitLiteral now reports every PERMISSION_PATTERN match with a symbolic-permission message, and the special-bit modes (01777, 02755, 04755) no longer match the narrowed pattern, so they get the generic "Use decimal values" message. The test file asserts all of these as Noncompliant. Reviewers and the RSPEC update driven from this description will describe the wrong behavior. Update the description so it says permission modes are still reported, but with a suggested symbolic string, and that special-bit modes get the generic message.

Verification Rules 1/1 met Repos 3 inspected

Functional validation No results

Rules 1 passed 2 not applicable

✅ Repository license compliance

Broader impact Repos 3 inspected

Cross-repo 3 repositories inspected 0 open impacts

SonarSource/sonarlint-intellij Inspected
SonarSource/sonarlint-vscode Inspected
SonarSource/sonarlint-eclipse Inspected

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing compact verification results.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[romainbrenguier]

/pvf S1314

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[hashicorp-vault-sonar-prod]

⚠️ Performance Validation finished without publishing a dashboard. See run logs.