apply suggestions from doc review

Author: erik-krogh

java/ql/src/Security/CWE/CWE-730/PolynomialReDoS.qhelp

@@ -105,7 +105,7 @@ Pattern.compile("^\\s+|\\s+$").matcher(text).replaceAll("") // BAD</sample>
         <p>
             Sometimes it is unclear how a regular expression can be rewritten to
             avoid the problem. In such cases, it often suffices to limit the
-            length of the input string. For instance, the following complicated 
+            length of the input string. For instance, the following 
             regular expression is used to match numbers, and on some non-number 
             inputs it can have quadratic time complexity:
         </p>
@@ -115,7 +115,7 @@ Pattern.matches("^(\\+|-)?(\\d+|(\\d*\\.\\d*))?(E|e)?([-+])?(\\d+)?$", str); </s
 
         <p>
             It is not immediately obvious how to rewrite this regular expression 
-            to avoid the problem. However, it might be fine to limit the length
+            to avoid the problem. However, you can mitigate performance issues by limiting the length
             to 1000 characters, which will always finish in a reasonable amount
             of time.
         </p>

javascript/ql/src/Performance/PolynomialReDoS.qhelp

@@ -105,7 +105,7 @@ text.replace(/^\s+|\s+$/g, ''); // BAD</sample>
         <p>
             Sometimes it is unclear how a regular expression can be rewritten to
             avoid the problem. In such cases, it often suffices to limit the
-            length of the input string. For instance, the following complicated 
+            length of the input string. For instance, the following 
             regular expression is used to match numbers, and on some non-number 
             inputs it can have quadratic time complexity:
         </p>
@@ -115,7 +115,7 @@ text.replace(/^\s+|\s+$/g, ''); // BAD</sample>
 
         <p>
             It is not immediately obvious how to rewrite this regular expression 
-            to avoid the problem. However, it might be fine to limit the length
+            to avoid the problem. However, you can mitigate performance issues by limiting the length
             to 1000 characters, which will always finish in a reasonable amount
             of time.
         </p>
@@ -124,6 +124,7 @@ text.replace(/^\s+|\s+$/g, ''); // BAD</sample>
 if (str.length &gt; 1000) {
     throw new Error("Input too long");
 }
+
 /^(\+|-)?(\d+|(\d*\.\d*))?(E|e)?([-+])?(\d+)?$/.test(str)</sample>
     </example>
 

python/ql/src/Security/CWE-730/PolynomialReDoS.qhelp

@@ -105,7 +105,7 @@ re.sub(r"^\s+|\s+$", "", text) # BAD</sample>
         <p>
             Sometimes it is unclear how a regular expression can be rewritten to
             avoid the problem. In such cases, it often suffices to limit the
-            length of the input string. For instance, the following complicated 
+            length of the input string. For instance, the following 
             regular expression is used to match numbers, and on some non-number 
             inputs it can have quadratic time complexity:
         </p>
@@ -115,7 +115,7 @@ match = re.search(r'^(\+|-)?(\d+|(\d*\.\d*))?(E|e)?([-+])?(\d+)?$', str) </sampl
 
         <p>
             It is not immediately obvious how to rewrite this regular expression 
-            to avoid the problem. However, it might be fine to limit the length
+            to avoid the problem. However, you can mitigate performance issues by limiting the length
             to 1000 characters, which will always finish in a reasonable amount
             of time.
         </p>

ruby/ql/src/queries/security/cwe-1333/PolynomialReDoS.qhelp

@@ -110,7 +110,7 @@ text.gsub!(/^\s+|\s+$/, '') # BAD</sample>
         <p>
             Sometimes it is unclear how a regular expression can be rewritten to
             avoid the problem. In such cases, it often suffices to limit the
-            length of the input string. For instance, the following complicated 
+            length of the input string. For instance, the following 
             regular expression is used to match numbers, and on some non-number 
             inputs it can have quadratic time complexity:
         </p>
@@ -120,7 +120,7 @@ is_matching = /^(\+|-)?(\d+|(\d*\.\d*))?(E|e)?([-+])?(\d+)?$/.match?(str)</sampl
 
         <p>
             It is not immediately obvious how to rewrite this regular expression 
-            to avoid the problem. However, it might be fine to limit the length
+            to avoid the problem. However, you can mitigate performance issues by limiting the length
             to 1000 characters, which will always finish in a reasonable amount
             of time.
         </p>