_STRONGWAR Strong Warnings Report

Top  Previous  Next


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.






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.







Possible bad typecast (consider using "as" for objects) (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.







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.




See also:


R_GEN General Reports