|
Targets: All except BP7 (partly)
This report generates warnings that help you identify especially severe errors. Those are errors that can cause runtime failures (“showstoppers”), or erroneous results in your application.
Property access in read/write methods (STWA1)
(Not relevant for BP7)
This section reports locations where properties are referenced in read/write methods, like for example:
These sorts of errors can cause infinite recursion.
Ambiguous unit references (STWA2)
This sections lists identifiers with ambiguous unit references.
Consider this example:
What will be the output from the program? In this case, it will be “Goodbye”, because the last unit listed in the uses clause will have precedence.
The reference to TheValue is ambiguous or unclear, so it will be listed in this report section. Consider what happens if originally only unit “A” was listed in the uses clause. Then the output would be “Hello”. If then maybe another programmer without any sense of danger will add “B” to the uses clause, the output will be changed.
You should prefix the reference, like “B.TheValue”, to avoid any uncertainty.
Subprogram calls itself unconditionally (STWA3)
This sections lists subprograms that call themselves unconditionally. This will lead to infinite recursion and stack failure at runtime if the subprogram is called:
Consider this example:
Currently overload subprograms are not examined.
Index error (STWA4)
This sections lists locations in your code with an index error.
Example:
If the code had been instead "Arr[553]" (an explicit value), the compiler would have halted on this line. But for a variable, it does not.
Possible bad pointer usage (STWA5)
This section lists locations in your code where a pointer possibly is misused. For example a pointer that has been set to nil and further down in the code is dereferenced.
Example:
Possible bad typecast (for objects: consider using "as") (STWA6)
This section lists locations in your code with a possibly bad typecast. If you use the "as" operator, an exception will instead be raised. Otherwise there may be access violations and errors in a totally different code location, which is not very easy to track down.
Example:
In the example above, the last line could better be written (although still faulty!) as
Monkey := Banana as TAnimal;
This should result in an exception. But this is still preferable; instead of letting the code proceed resulting maybe in access violations later in a totally unrelated part of the code.
Also situations where a "bigger" type is typecast to a "smaller", will trigger a warning. For example "Ch := Char(I)" where Ch is of type Char and I is of type Integer. This may of course be totally valid if you make sure that I is not too big.
For-loop with possible bad conditions (STWA7)
This section lists locations in your code where for loop has any of these conditions:
Bad parameter usage (same identifier used for different parameter) (STWA8)
This section lists locations in your code where a call to a subprogram is made with bad parameters. The situation occurs when the called subprogram has an "out" parameter plus at least one another parameter. The identifier passed is used for both these parameters. Because an "out"-parameter is cleared in the called subprogram this will give unexpected results for reference-counted variables like strings and dynamic arrays.
Generic interface has GUID (STWA9)
This section lists generic interface types that declare a GUID:
The problem with this is that all generic types created from this interface, like IMyInterface<Integer> and IMyInterface<string> will share the same GUID.
This will cause type casting to malfunction.
Interface lacks GUID (STWA10)
This section lists interface types that lacks a GUID.
See also:
 General Reports
| 
Strong Warnings Report