Custom Query (74 matches)

This is an updated request on this feature in addition to the issue report of the mail thread below. The goal of this request is to create a set of configuration parameters to be able to use the feature checkNoUninitialisedVariables.

Problem:

As discussed, we have no means to initialise each an every variable because, due to our coding style, there are situations where the value to apply is only known depending on a branch of the code so giving always an initial value is not a possible solution for us. Same happens with most of our user defined types, as we can't set (or sometimes we just avoid it) a value which is not valid to initialise arrays, lists or enumerated variables.

Our approach to keep on using this feature so far is to run the tool against single files with the feature enabled and avoid using it to run a whole ATS.

Possible solution:

Currently on configuration file "t3q-v2.xml" we have the following parameter to enable the feature

<checkNoUninitialisedVariables>false</checkNoUninitialisedVariables>

The idea is to create more configuration parameters embedded on the one above so that I could use the tool against ATSs seeking also for uninitialised variables but discarding some warnings under certain conditions.

Proposal of update on the configuration file.

<checkNoUninitialisedVariables>true</checkNoUninitialisedVariables>

<typesNotCheckedNoUninitialisedVariables> <!-- types to be discarded if checkNoUninitialisedVariables is true. If list if empty, no restrictions -->

<string>enumerated</string> <string>union</string> <string>record of</string> <string>record</string> <string>set</string> <string>set of</string>

</typesNotCheckedNoUninitialisedVariables>

With the selection above, I can tune the tool to have a global view and discard some types that are eventually raising unwanted warnings on this feature. If I run the tool over a whole ATS I would like to have this possibility.

When running the tool for a single file, I would set the list empty and therefore look for any possible uninitialised variable.

The maximum set of types I thought of for this enhancement is the one above, again:

<string>enumerated</string> <string>union</string> <string>record of</string> <string>record</string> <string>set</string> <string>set of</string>

Summarising, proposal on update of the configuration file:

• If checkNoUninitialisedVariables=false then no content on typesNotCheckedNoUninitialisedVariables is used (or simply typesNotCheckedNoUninitialisedVariables will not appear on the configuration file)

• If checkNoUninitialisedVariables=true then some content on typesNotCheckedNoUninitialisedVariables can apply and if empty/non existing, no restriction applies looking for warnings.

The tool on b24 is raising a warning as follows:

Validation output of ..\ttcn\Common\NAS\SMS_Templates.ttcn ..\ttcn\Common\NAS\SMS_Templates.ttcn: 505: WARNING: Code Style: Local definition for "v_Received_CP_PDU" in definition of "f_SMS_CP_PDU_DecodeAndMatch" is not initialised! (6.10, checkNoUninitialisedVariables)

But v_Received_CP_PDU is an out variable, as it is used on

var integer v_DecodeResult := decvalue(p_EncodedSMS_Message, *v_Received_CP_PDU*);

Therefore it should not be raised as a warning. I think on b24 the issues with inout variables are solved now but the ones with only out variables remain.

Currently parsing issues are not reported in the command line tooling. They are only visible in the GUI editor. There should at be an option to activate parsing issues for command line use at the very least for debugging (DEBUG and FIXME log levels).