Merge branch 'master' into rule/add-RSPEC-S6958

frontend/public/covered_rules.json

@@ -1918,8 +1918,8 @@
     "S6802": "sonar-dotnet 9.14.0.81108",
     "S6803": "sonar-dotnet 9.14.0.81108",
     "S6930": "sonar-dotnet 9.22.0.87781",
-    "S6931": "sonar-dotnet master",
-    "S6934": "sonar-dotnet master",
+    "S6931": "sonar-dotnet 9.23.0.88079",
+    "S6934": "sonar-dotnet 9.23.0.88079",
     "S818": "sonar-dotnet 6.6.0.3969",
     "S881": "sonar-dotnet 7.1.0.5212",
     "S907": "sonar-dotnet 6.6.0.3969",
@@ -5037,13 +5037,13 @@
     "S6894": "sonar-python 4.16.0.14672",
     "S6900": "sonar-python 4.16.0.14672",
     "S6903": "sonar-python 4.16.0.14672",
-    "S6908": "sonar-python master",
-    "S6911": "sonar-python master",
-    "S6918": "sonar-python master",
-    "S6919": "sonar-python master",
-    "S6925": "sonar-python master",
-    "S6928": "sonar-python master",
-    "S6929": "sonar-python master",
+    "S6908": "sonar-python 4.17.0.14845",
+    "S6911": "sonar-python 4.17.0.14845",
+    "S6918": "sonar-python 4.17.0.14845",
+    "S6919": "sonar-python 4.17.0.14845",
+    "S6925": "sonar-python 4.17.0.14845",
+    "S6928": "sonar-python 4.17.0.14845",
+    "S6929": "sonar-python 4.17.0.14845",
     "S905": "sonar-python 2.11.0.6843",
     "S930": "sonar-python 2.4.0.5513",
     "S935": "sonar-python 4.6.0.12071"
@@ -6264,7 +6264,7 @@
     "S6613": "sonar-dotnet 9.1.0.70676",
     "S6617": "sonar-dotnet 9.1.0.70676",
     "S6930": "sonar-dotnet 9.22.0.87781",
-    "S6931": "sonar-dotnet master",
+    "S6931": "sonar-dotnet 9.23.0.88079",
     "S907": "sonar-dotnet 8.11.0.20529",
     "S927": "sonar-dotnet 8.18.0.27296"
   },

rules/S1186/jcl/metadata.json

@@ -0,0 +1,3 @@
+{
+  "title": "Procedures should not be empty"
+}

rules/S1186/jcl/rule.adoc

@@ -0,0 +1,44 @@
+== Why is this an issue?
+
+:operationName: procedure
+
+include::../description.adoc[]
+
+== How to fix it
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,jcl,diff-id=1,diff-type=noncompliant]
+----
+//MYPROC PROC
+//       PEND
+----
+
+==== Compliant solution
+
+[source,java,diff-id=1,diff-type=compliant]
+----
+//MYPROC PROC
+//RUN    EXEC PGM=MYPROG
+//       PEND
+----
+
+ifdef::env-github,rspecator-view[]
+
+'''
+== Implementation Specification
+(visible only on this page)
+
+=== Message
+
+Complete the implementation of this procedure.
+
+'''
+== Comments And Links
+(visible only on this page)
+
+include::../comments-and-links.adoc[]
+
+endif::env-github,rspecator-view[]

rules/S1854/cfamily/rule.adoc

@@ -182,9 +182,6 @@ void caller() {
 
 * S1763 - All code should be reachable
 * S2583 - Conditionally executed code should be reachable
-* S2589 - Boolean expressions should not be gratuitous
-* S3516 - Methods returns should not be invariant
-* S3626 - Jump statements should not be redundant
 
 ifdef::env-github,rspecator-view[]
 

rules/S2275/cfamily/rule.adoc

@@ -1,10 +1,11 @@
 == Why is this an issue?
 
-Because ``++printf++`` format strings are interpreted at runtime, rather than validated by the compiler, they can contain errors that lead to unexpected behavior or runtime errors. This rule statically validates the good behavior of ``++printf++`` formats.
-
+Because `printf` format strings are interpreted at runtime rather than validated by the compiler, they can contain errors that lead to unexpected behavior or runtime errors. This rule statically validates the good behavior of `printf` formats.
 
 The related rule S3457 is about errors that produce an unexpected string, while this rule is about errors that will create undefined behavior.
 
+Starting with {cpp}23, `std::print` should be preferred: its arguments are validated at compile-time, making it more secure.
+
 === Noncompliant code example
 
 [source,cpp]
@@ -36,7 +37,15 @@ This rule will only work if the format string is provided as a string literal.
 
 == Resources
 
-* https://www.securecoding.cert.org/confluence/x/wQA1[CERT, FIO47-C.] - Use valid format strings
+=== Standards
+
+* CERT - https://www.securecoding.cert.org/confluence/x/wQA1[FIO47-C. Use valid format strings]
+
+=== Related rules
+
+* S3457 - Format strings should be used correctly
+* S5281 - Argument of "printf" should be a format string
+* S6494 - {cpp} formatting functions should be used instead of C printf-like functions
 
 ifdef::env-github,rspecator-view[]
 

rules/S2589/cfamily/metadata.json

@@ -1,4 +1,5 @@
 {
+  "status": "closed",
   "tags": [
     "cwe",
     "based-on-misra",
@@ -8,9 +9,7 @@
     "redundant",
     "misra-c2012"
   ],
-  "defaultQualityProfiles": [
-    "Sonar way"
-  ],
+  "defaultQualityProfiles": [],
   "securityStandards": {
     "CERT": [
       "MSC12-C."

rules/S2589/comments-and-links.adoc

@@ -9,3 +9,6 @@ Question : should we consider this RSPEC as being fully a subset of RSPEC-2583 ?
 
 === on 29 Feb 2016, 08:37:04 Pierre-Yves Nicolas wrote:
 \[~freddy.mallet] I don't really see why this RSPEC is "fully a subset of RSPEC-2583". Maybe that makes sense if it is implemented through symbolic execution with short-circuit logical operators, but then it all depends on the order of sub-conditions. Please consider ``++IF X > 1 AND X = 5++``: I think that this code would raise an issue for the current description of this RSPEC, but not for RSPEC-2583.
+
+=== on 26 Mar 2024, 08:15:00 Philipp Dominik Schubert wrote:
+We created a circle to discuss CFamily's rules on dead code and decided to disable this rule in the CFamily analyzer since we believe it provides relatively low value and is not even implemented in CFamily's analyzer (cf. https://sonarsource.atlassian.net/browse/CPP-5165).

rules/S2647/metadata.json

@@ -7,14 +7,12 @@
     },
     "attribute": "TRUSTWORTHY"
   },
-  "status": "ready",
+  "status": "deprecated",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "2h"
   },
-  "tags": [
-    "cwe"
-  ],
+  "tags": [],
   "extra": {
     "replacementRules": [],
     "legacyKeys": []
@@ -43,8 +41,6 @@
       "2.10.3"
     ]
   },
-  "defaultQualityProfiles": [
-    "Sonar way"
-  ],
+  "defaultQualityProfiles": [],
   "quickfix": "unknown"
 }

rules/S3516/cfamily/metadata.json

@@ -1,12 +1,11 @@
 {
+  "status": "closed",
   "code": {
     "impacts": {
       "MAINTAINABILITY": "MEDIUM"
     },
     "attribute": "LOGICAL"
   },
   "defaultSeverity": "Major",
-  "defaultQualityProfiles": [
-    "Sonar way"
-  ]
+  "defaultQualityProfiles": []
 }

rules/S3516/comments-and-links.adoc

@@ -1,2 +1,4 @@
 === relates to: S3400
 
+=== on 26 Mar 2024, 08:15:00 Philipp Dominik Schubert wrote:
+We created a circle to discuss CFamily's rules on dead code and decided to disable this rule in the CFamily analyzer since we believe it provides relatively low value and is not even implemented in CFamily's analyzer (cf. https://sonarsource.atlassian.net/browse/CPP-5165).

rules/S3626/cfamily/metadata.json

@@ -1,5 +1,4 @@
 {
-  "defaultQualityProfiles": [
-    "Sonar way"
-  ]
+  "status": "closed",
+  "defaultQualityProfiles": []
 }

rules/S3626/comments-and-links.adoc

@@ -11,3 +11,5 @@ Note that there is a potential overlap of this rule with RSPEC-1751: uncondition
 === on 2 Jun 2016, 14:05:22 Ann Campbell wrote:
 looks fine [~tamas.vajk]
 
+=== on 26 Mar 2024, 08:15:00 Philipp Dominik Schubert wrote:
+We created a circle to discuss CFamily's rules on dead code and decided to disable this rule in the CFamily analyzer since we believe it provides relatively low value and is not even implemented in CFamily's analyzer (cf. https://sonarsource.atlassian.net/browse/CPP-5165).

rules/S3735/javascript/rule.adoc

@@ -42,7 +42,7 @@ void function() {
 }();
 ----
 
-* `void` is allowed with Promise-like objects to mark a promise as intentionally not awaited, as advised by https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-floating-promises.md[@typescript-eslint/no-floating-promises].
+* `void` is allowed with Promise-like objects to mark a promise as intentionally not awaited, as advised by https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-floating-promises.mdx[@typescript-eslint/no-floating-promises].
 
 [source,javascript]
 ----

rules/S5194/java/metadata.json

@@ -1,5 +1,5 @@
 {
-  "title": "Use Java 12 \"switch\" expression",
+  "title": "Use Java 14 \"switch\" expression",
   "type": "CODE_SMELL",
   "code": {
     "impacts": {
@@ -13,7 +13,7 @@
     "constantCost": "5min"
   },
   "tags": [
-    "java12"
+    "java14"
   ],
   "extra": {
     "replacementRules": [

rules/S5194/java/rule.adoc

@@ -3,7 +3,7 @@
 Many existing switch statements are essentially simulations of switch expressions, where each arm either assigns to a common target variable or returns a value. Expressing this as a statement is roundabout, repetitive, and error-prone.
 
 
-Java 12 added support for switch expressions, which provide more succinct and less error-prone version of switch.
+Java 14 added support for switch expressions, which provide more succinct and less error-prone version of switch.
 
 
 === Noncompliant code example

rules/S5281/cfamily/rule.adoc

@@ -1,10 +1,11 @@
 == Why is this an issue?
 
-It is a security vulnerability to call ``++printf++`` with a unique string argument which is not a string literal. Indeed, if this argument comes from a user input, this user can :
+It is a security vulnerability to call `printf` with a unique string argument that is not a string literal. Indeed, if this argument comes from a user input, this user can:
 
-* make the program crash, by executing code equivalent to: ``++printf("%s%s%s%s%s%s%s%s")++``
-* view the stack or a memory at any location, by executing code equivalent to: ``++printf("%08x %08x %08x %08x %08x\n")++``
+* make the program crash by executing code equivalent to: ``++printf("%s%s%s%s%s%s%s%s")++``
+* view the stack or memory at any location by executing code equivalent to: ``++printf("%08x %08x %08x %08x %08x\n")++``
 
+Starting with {cpp}23, `std::print` should be preferred: its arguments are validated at compile-time, making it more secure.
 
 === Noncompliant code example
 
@@ -28,7 +29,18 @@ void f(char* userInput) {
 
 == Resources
 
-* https://owasp.org/www-community/attacks/Format_string_attack[Owasp: format string attack]
+=== Documentation
+
+* {cpp} reference - https://en.cppreference.com/w/cpp/io/c/fprintf[`printf`]
+
+=== Standards
+
+* OWASP - https://owasp.org/www-community/attacks/Format_string_attack[Format string attack]
+
+=== Related rules
+
+* S2275 - Printf-style format strings should not lead to unexpected behavior at runtime
+* S6494 - {cpp} formatting functions should be used instead of C printf-like functions
 
 
 ifdef::env-github,rspecator-view[]