Executes a specific block of PSL code based on the value of a variable.

Syntax

 switch ( expression )
{ 
case a : { BLOCK }
case b : { BLOCK } 
. . .
case p ,q, r : { BLOCK } 
. . .
case n: { BLOCK } 
default: { BLOCK } 
}

Parameters

Description

The switch statement evaluates expression and based on its integer value executes a specific PSL BLOCK. The case labels correspond to the values of expression for which a specific PSL BLOCK is available.

If the value of expression falls outside the range of the values in the case labels, execution continues with the BLOCK corresponding to the default label. If no default label exists, execution will continue with the first statement following the switch statement.

The switch statement is similar in form and function to the C switch statement.

The PSL switch statement executes in almost the same way as a long sequence of if - then - else - if statements. A case or default clause is effectively a run-time statement that specifies a comparison against the value of expression:

• If the value of expression matches a case, execution moves inside the BLOCK for the case or default clause; and after completing BLOCK, execution continues after the entire switch statement (that is, there is no falling through to the next case clause).
• If the value of expression does not match a case, execution skips to the default clause; and if there is none, execution moves to the statement following the switch statement.

Any statement within the switch statement case block that is not part of a case or default BLOCK executes only if all the case labels above it failed to match expression (that is, it executes as part of the normal sequence of control flow).

Differences between the PSL and C switch Statements

The following differences exist between the PSL switch statement and the C switch statement:

• PSL case expressions can be dynamically evaluated expressions whereas C only permits constant expressions.
• The colon delimiter that separates the case label from the executable BLOCK is optional in PSL and required in C.
• PSL requires that the default label follow all case labels in the switch statement case block, whereas C allows default to appear anywhere within the case labels. PSL returns a compilation error if one or more case labels follow default.
• PSL does not return a compilation error for duplicate case labels in the switch statement case block, whereas C does. In PSL, the second of the duplicate case labels is unreachable.
• PSL allows multiple cases that execute a common BLOCK to be specified as a comma separated list within a single case label, where C requires that each case be a separate case label stacked above a single BLOCK. (Conversely, the stacked labels will not work in PSL.)
• Execution of a PSL BLOCK does not fall through to the next case label and BLOCK, as it does the C switch statement. Upon reaching the closing right brace of a case or default BLOCK, execution moves to the end of the PSL switch statement.
• The PSL switch statement uses the last statement to exit from a BLOCK, whereas C uses the break statement. The last statement exits the innermost switch statement or loop. However, because of the absence of fall-through in PSL, there is little need to use the last statement in the switch statement.

Similarities between the PSL and C switch Statements

The following similarities exist between the PSL switch statement and the C switch statement:

• both generate a compiler error upon detecting two default labels in a single switch statement
• both permit nested switch statements

Efficiency of switch Statements versus if-then-elsif Sequences

Because of the similar method of implementation, there is almost no difference in efficiency between PSL switch statements and if - then - elsif sequences. Programming style is the main consideration in the choice. To speed up switch statements, BMC Software recommends that you specify the most likely cases first. The speedup is also true of if - then - elsif sequences.

Pitfall: switch Statement case Labels That Modify case Variables

The case BLOCKs are evaluated at run-time in their order of appearance:

• case order for BLOCKs
• left-to-right for expressions in the comma-separated lists of multiple-case labels

All expressions within a comma-separated list are evaluated before the case label. This evaluation occurs even if the first expression is a match.

This sequence and method of evaluating the case label can be a dangerous pitfall if any expression in the list modifies either variable for the current switch statement or a variable used in another case expression.

Pitfall: Statements Inside a switch Statement That Are Not Part of a BLOCK

Under PSL, statements within a switch statement that are not part of a BLOCK (free statements) can and will be executed if they are reached by the flow of execution. The condition for control flow to reach these statements is that variable cannot match any of the case labels that precede them within the switch statement.

Pitfall: Nesting case Labels That Use the Same Variable

PSL does not return a warning or error message when two case labels evaluated against expression are nested one inside the other. Two examples of this situation are shown in the following PSL switch example:

switch(x)
{
	case 1:
	{ 
	f1()					 	# Function f1 Called
	case 2 :{f2();} 		 	# Function f2 Unreachable
	f3(); 					 	# Function f3 Called
	}
	default: {case 4: {f4();}}  # Function f4 called if x=4
}

Since case and default labels are run-time statements, the effect of one case label nested within another is that expression must match the case value for the case BLOCK to execute. This means that expression must equal two different values! In case 1 of the example, f2 will never be called because x cannot equal both 1 and 2.

In the default case of the example, f4 will be called if expression = 4 because there is no case 4 defined in the switch statement. When expression = 4, the default BLOCK executes, containing the case 4 BLOCK call to function f4.

Although nesting case labels within one another is possible and may have some utility, BMC Software views them as a potential pitfall both because of the possibility of creating unreachable BLOCKs and because future PSL versions may not support case label nesting.

Where to go from here

PSL Statements