Bugs from FindBugs

[MengqiLin]

These are the bugs that detected by FindBugs in eclipse

1. Scariest(3)
   1.1 High confidence(1)：

1. Location: Line 32 in Matrix.java
   System.out.println("m3=="MATRIX": " + m2.equals("MATRIX")); //false
   Reason: Call to equals() comparing different types

   Bug: Call to DataStructures.Matrix.Matrix.equals(String) in DataStructures.Matrix.Matrix.main(String[])

This method calls equals(Object) on two references of different class types and analysis suggests they will be to objects of different classes at runtime. Further, examination of the equals methods that would be invoked suggest that either this call will always return false, or else the equals method is not be symmetric (which is a property required by the contract for equals in class Object).
Rank: Scariest (1), confidence: High
Pattern: EC_UNRELATED_TYPES
Type: EC, Category: CORRECTNESS (Correctness)

1.2 Normal confidence(2)：
1), Location: Line 35 in Matrix.java
System.out.println("m2==m2: " + m2.equals(m2)); //true
Reason: Self comparison of value with itself
Bug: Self comparison of DataStructures.Matrix.Matrix.equals(Matrix) with itself DataStructures.Matrix.Matrix.main(String[])

This method compares a local variable with itself, and may indicate a typo or a logic error. Make sure that you are comparing the right things.
Rank: Scariest (3), confidence: Normal
Pattern: SA_LOCAL_SELF_COMPARISON
Type: SA, Category: CORRECTNESS (Correctness)

2), Location: Line 19 in CirclLinkedList.java
head = new Node(null,head);
Reason: Uninitialized read of field constructor
Bug: Uninitialized read of head in new DataStructures.Lists.CircleLinkedList()

This constructor reads a field which has not yet been assigned a value. This is often caused when the programmer mistakenly uses the field instead of one of the constructor's parameters.
Rank: Scariest (3), confidence: Normal
Pattern: UR_UNINIT_READ
Type: UR, Category: CORRECTNESS (Correctness)

2. Scary(10)
   2.1 High confidence(7):

1. Location: Line 337 in AES.java
   int cellBitsLength = cellBits.length();
   while (cellBitsLength < 8) {
   cellBits = '0' + cellBits;
   }
   Reason: An apparent infinite loop
   Bug: There is an apparent infinite loop in ciphers.AES.mergeCellsIntoBlock(int[])
   This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
   Rank: Scary (8), confidence: High
   Pattern: IL_INFINITE_LOOP
   Type: IL, Category: CORRECTNESS (Correctness)

2. Location: Line 223 in AES.java
   int currentByteBitsLength = currentByteBits.length();
   while (currentByteBitsLength < 2) {
   currentByteBits = '0' + currentByteBits;
   }
   Reason: An apparent infinite loop

Bug: There is an apparent infinite loop in ciphers.AES.scheduleCore(BigInteger, int)
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
Rank: Scary (8), confidence: High
Pattern: IL_INFINITE_LOOP
Type: IL, Category: CORRECTNESS (Correctness)

3. Location: Line 206 in AES.java
   int rBytesLength = rBytes.length();
   while (rBytesLength < 8) {
   rBytes = "0" + rBytes;
   }
   Reason: An apparent infinite loop
   Bug: There is an apparent infinite loop in ciphers.AES.scheduleCore(BigInteger, int)
   This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
   Rank: Scary (8), confidence: High
   Pattern: IL_INFINITE_LOOP
   Type: IL, Category: CORRECTNESS (Correctness)

4. Location: Line 308 AES.java
   int blockBitsLength = blockBits.length();
   while (rBytesLength < 8) {
   rBytes = "0" + rBytes;
   }
   Reason: An apparent infinite loop

Bug: There is an apparent infinite loop in ciphers.AES. splitBlockIntoCells(BigInteger)
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
Rank: Scary (8), confidence: High
Pattern: IL_INFINITE_LOOP
Type: IL, Category: CORRECTNESS (Correctness)

5. Location: Line 70 StackOfLinkedList.java
   Node temp = head;
   head = head.next;
   Reason: Possible null pointer dereference
   Bug: Possible null pointer dereference of temp in DataStructures.Stacks.LinkedListStack.pop()
   There is a branch of statement that, if executed, guarantees that a null value will be dereferenced, which would generate a NullPointerException when the code is executed. Of course, the problem might be that the branch or statement is infeasible and that the null pointer exception can't ever be executed; deciding that is beyond the ability of FindBugs.
   Rank: Scary (6), confidence: High
   Pattern: NP_NULL_ON_SOME_PATH
   Type: NP, Category: CORRECTNESS (Correctness)

6. Location: Line 90 DoublyLinkedList.java
   head = head.next; // oldHead <--> 2ndElement(head)
   head.previous = null; // oldHead --> 2ndElement(head) nothing pointing at old head so will be removed
   Reason: Nullcheck of value pervious dereferenced
   Bug: Nullcheck of DoublyLinkedList.head at line 91 of value previously dereferenced in DataStructures.Lists.DoublyLinkedList.deleteHead()
   A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
   Rank: Scary (9), confidence: High
   Pattern: RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
   Type: RCN, Category: CORRECTNESS (Correctness)

7. Location: Line 104 DoublyLinkedList.java
   Link temp = tail;
   tail = tail.previous; // 2ndLast(tail) <--> oldTail --> null
   tail.next = null; // 2ndLast(tail) --> null
   Reason: Nullcheck of value pervious dereferenced
   Bug: Nullcheck of DoublyLinkedList.head at line 91 of value previously dereferenced in DataStructures.Lists.DoublyLinkedList.deleteHead()
   A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
   Rank: Scary (9), confidence: High
   Pattern: RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
   Type: RCN, Category: CORRECTNESS (Correctness)

2.2 Normal confidence(3)：

1. Location: Line 217 Matrix.java
   if (this.getRows() != other.getRows() || this.getColumns() != other.getColumns())
   return false;
   Reason: Covariant equals() method defined , Object equals(Object) inherited
   Bug: DataStructures.Matrix.Matrix defines equals(Matrix) method and uses Object.equals(Object)

This class defines a covariant version of the equals() method, but inherits the normal equals(Object) method defined in the base java.lang.Object class. The class should probably define a boolean equals(Object) method.
Rank: Scary (8), confidence: Normal
Pattern: EQ_SELF_USE_OBJECT
Type: Eq, Category: CORRECTNESS (Correctness)

2. Location: Line 124 HeapElement.java
   return (this.key == otherHeapElement.key) && (this.additionalInfo.equals(otherHeapElement.additionalInfo));

Reason: Covariant equals() method defined , Object equals(Object) inherited
Bug: DataStructures.Heaps.HeapElement defines equals(HeapElement) method and uses Object.equals(Object)
This class defines a covariant version of the equals() method, but inherits the normal equals(Object) method defined in the base java.lang.Object class. The class should probably define a boolean equals(Object) method.
Rank: Scary (8), confidence: Normal
Pattern: EQ_SELF_USE_OBJECT
Type: Eq, Category: CORRECTNESS (Correctness)

3. Location: Line 32 Matrix.java
   System.out.println("m2==null: " + m2.equals(null)); //false
   Reason: Method call passes null for non-null parameter
   Bug: Null passed for non-null parameter of equals(Matrix) in DataStructures.Matrix.Matrix.main(String[])
   A possibly-null value is passed at a call site where all known target methods require the parameter to be non-null. Either the parameter is annotated as a parameter that should always be non-null, or analysis has shown that it will always be dereferenced.
   Rank: Scary (8), confidence: Normal
   Pattern: NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS
   Type: NP, Category: CORRECTNESS (Correctness)

3. Troubling(5)
   3.1 High confidence(1)

1. Location: Line 88 BinaryTreeSort.java
   Double[] decimalArray = {8.2, 1.5, 3.14159265, 9.3, 5.1, 4.8, 2.6};
   Reason: Rough value of known constant found

Bug: Rough value of Math.PI found: 3.14159265
It's recommended to use the predefined library constant for code clarity and better precision.
Rank: Troubling (14), confidence: High
Pattern: CNT_ROUGH_CONSTANT_VALUE
Type: CNT, Category: BAD_PRACTICE (Bad practice)

3.2 Normal confidence(4)：

1. Location: Line 19 Foo.java
   if (Integer.toString(50) == Byte.toString(b[i]))
   Reason: Comparison of String objects using == or ! =
   Bug: Comparison of String objects using == or != in test.Foo.bar()
   This code compares java.lang.String objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the String.intern() method, the same string value may be represented by two different String objects. Consider using the equals(Object) method instead.
   Rank: Troubling (11), confidence: Normal
   Pattern: ES_COMPARING_STRINGS_WITH_EQ
   Type: ES, Category: BAD_PRACTICE (Bad practice)

2. Location: Line 53 TopKWords.java
   fis.close();
   Reason: Value is null and guaranteed to be dereferenced on exception path
   Bug: fis is null guaranteed to be dereferenced in Others.TopKWords$CountWords.getDictionary() on exception path
   There is a statement or branch on an exception path that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).
   Rank: Troubling (11), confidence: Normal
   Pattern: NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH
   Type: NP, Category: CORRECTNESS (Correctness)

3. Location: Line 32 removeDuplicateFromString.java
   if(s.isEmpty() || s == null) {
   return s;
   }
   Reason: Nullcheck of value previously dereferenced
   Bug: Nullcheck of s at line 32 of value previously dereferenced in Others.removeDuplicateFromString.removeDuplicate(String)
   A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
   Rank: Troubling (11), confidence: Normal
   Pattern: RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
   Type: RCN, Category: CORRECTNESS (Correctness)

4. Location: Line 32 removeDuplicateFromString.java
   if(str.isEmpty() || str == null) return str;
   Reason: Nullcheck of value previously dereferenced
   Bug: Nullcheck of str at line 22 of value previously dereferenced in Others.ReverseString.reverse(String)
   A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.
   Rank: Troubling (11), confidence: Normal
   Pattern: RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
   Type: RCN, Category: CORRECTNESS (Correctness)

4. Of concern(11)
   4.1 High confidence(7)：

1. Location: Line 118 CSVFile.java
   ArrayList colums = new ArrayList();
   Reason: Dead store to local variable
   Bug: Dead store to colums in new DataStructures.CSVFile.src.CSVFile(File, char)
   This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used. Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
   Rank: Of Concern (15), confidence: High
   Pattern: DLS_DEAD_LOCAL_STORE
   Type: DLS, Category: STYLE (Dodgy code)

2. Location: Line 146 TestCSVFile.java
   CSVFile testObj = new CSVFile("testData4.csv",',');
   Reason: Dead store to local variable
   Bug: Dead store to testObj in DataStructures.CSVFile.src.TestCSVFile.testRemoving()
   This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used. Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.
   Rank: Of Concern (15), confidence: High
   Pattern: DLS_DEAD_LOCAL_STORE
   Type: DLS, Category: STYLE (Dodgy code)

3. Location: Line 93 NodeStack.java
   NodeStack.head = NodeStack.head.getPrevious();
   Reason: Write to static field from instance method
   Bug: Write to static field DataStructures.Stacks.NodeStack.head from instance method DataStructures.Stacks.NodeStack.pop()
   This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
   Rank: Of Concern (15), confidence: High
   Pattern: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD
   Type: ST, Category: STYLE (Dodgy code)

4. Location: Line 78 NodeStack.java
   NodeStack.head = newNs;
   Reason: Write to static field from instance method
   Bug: Write to static field DataStructures.Stacks.NodeStack.head from instance method DataStructures.Stacks.NodeStack.push(Object)
   This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
   Rank: Of Concern (15), confidence: High
   Pattern: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD
   Type: ST, Category: STYLE (Dodgy code)

5. Location: Line 269 ClosesPair.java
   minNum = length;
   Reason: Write to static field from instance method
   Bug: Write to static field divideconquer.ClosestPair.minNum from instance method divideconquer.ClosestPair.bruteForce(ClosestPair$Location[])
   This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
   Rank: Of Concern (15), confidence: High
   Pattern: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD
   Type: ST, Category: STYLE (Dodgy code)

6. Location: Line 232 ClosesPair.java
   minNum = length;
   Reason: Write to static field from instance method
   Bug: Write to static field divideconquer.ClosestPair.minNum from instance method divideconquer.ClosestPair.closestPair(ClosestPair$Location[], int)
   This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
   Rank: Of Concern (15), confidence: High
   Pattern: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD
   Type: ST, Category: STYLE (Dodgy code)

7. Location: Line 195 NodeStack.java
   if (xGap < minValue) {
   secondCount++; // size of the array
   }
   Reason: Write to static field from instance method
   Bug: Write to static field divideconquer.ClosestPair.secondCount from instance method divideconquer.ClosestPair.closestPair(ClosestPair$Location[], int)
   This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.
   Rank: Of Concern (15), confidence: High
   Pattern: ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD
   Type: ST, Category: STYLE (Dodgy code)

4.2 Normal confidence(4)：

1. Location: Line 21 AnyBaseToDecimal.java
   System.out.println("Decimal value of " + inp + " is: " + convertToDecimal(inp, base));
   Reason: Dereference of result of readLine() without nullcheck
   Bug: Dereference of the result of readLine() without nullcheck in Conversions.AnyBaseToDecimal.main(String[])
   The result of invoking readLine() is dereferenced without checking to see if the result is null. If there are no more lines of text to read, readLine() will return null and dereferencing that will generate a null pointer exception.
   Rank: Of Concern (15), confidence: Normal
   Pattern: NP_DEREFERENCE_OF_READLINE_VALUE
   Type: NP, Category: STYLE (Dodgy code)

2. Location: Line 28 MinimizingLateness.java
   indexCount = Integer.parseInt(ch); // The first line specifies the size of the operation (= the size of the array)
   Reason: Dereference of result of readLine() without nullcheck
   Bug: Dereference of the result of readLine() without nullcheck in MinimizingLateness.MinimizingLateness.main(String[])
   The result of invoking readLine() is dereferenced without checking to see if the result is null. If there are no more lines of text to read, readLine() will return null and dereferencing that will generate a null pointer exception.
   Rank: Of Concern (15), confidence: Normal
   Pattern: NP_DEREFERENCE_OF_READLINE_VALUE
   Type: NP, Category: STYLE (Dodgy code)

3. Location: Line 18 removeDuplicateFromString.java
   System.out.println("String after removing duplicates: " + removeDuplicate(inp_str));
   Reason: Dereference of result of readLine() without nullcheck
   Bug: Dereference of the result of readLine() without nullcheck in Others.removeDuplicateFromString.main(String[])
   The result of invoking readLine() is dereferenced without checking to see if the result is null. If there are no more lines of text to read, readLine() will return null and dereferencing that will generate a null pointer exception.
   Rank: Of Concern (15), confidence: Normal
   Pattern: NP_DEREFERENCE_OF_READLINE_VALUE
   Type: NP, Category: STYLE (Dodgy code)

4. Location: Line 44 ReverseString.java
   System.out.println("Reverse="+reverse(srr));
   Reason: Dereference of result of readLine() without nullcheck
   Bug: Dereference of the result of readLine() without nullcheck in Others.ReverseString.main(String[])
   The result of invoking readLine() is dereferenced without checking to see if the result is null. If there are no more lines of text to read, readLine() will return null and dereferencing that will generate a null pointer exception.
   Rank: Of Concern (15), confidence: Normal
   Pattern: NP_DEREFERENCE_OF_READLINE_VALUE
   Type: NP, Category: STYLE (Dodgy code)

[yanglbme]

Hi @MengqiLin, thanks for comming to report the bugs in branch master.

I'll try to fix the bugs

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Please reopen this issue once you add more information and updates here. If this is not the case and you need some help, feel free to seek help from our Gitter or ping one of the reviewers. Thank you for your contributions!