Baseline for Ed 2 of tr 24772

6.31 Structured Programming [EWD]

6.31.1 Description of application vulnerability

Programs that have a convoluted control structure are likely to be more difficult to be human readable, less understandable, harder to maintain, harder to statically analyze, more difficult to match the allocation and release of resources, and more likely to be incorrect.

6.31.2 Cross reference

JSF AV Rules: 20, 113, 189, 190, and 191

MISRA C 2012: 15.1-15.3, and 21.4

MISRA C++ 2008: 6-6-1, 6-6-2, 6-6-3, and 17-0-5

CERT C guidelines: SIG32-C

Ada Quality and Style Guide: 3, 4, 5.4, 5.6, and 5.7

6.31.3 Mechanism of failure

Lack of structured programming can lead to:

• 
  Memory or resource leaks.
  
• 
  Error-prone maintenance.
  
• 
  Design that is difficult or impossible to validate.
  
• 
  Source code that is difficult or impossible to statically analyze.
  

6.31.4 Applicable language characteristics

This vulnerability description is intended to be applicable to languages with the following characteristics:

• 
  Languages that allow leaving a loop without consideration for the loop control.
  
• 
  Languages that allow local jumps (goto statement).
  
• 
  Languages that allow non-local jumps (setjmp/longjmp in the C programming language).
  
• 
  Languages that support multiple entry and exit points from a function, procedure, subroutine or method.
  

6.31.5 Avoiding the vulnerability or mitigating its effects

Use only those features of the programming language that enforce a logical structure on the program. The program flow follows a simple hierarchical model that employs looping constructs such as for, repeat, do, and while.

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Avoid using language features such as goto.
  
• 
  Avoid using language features such as continue and break in the middle of loops.
  
• 
  Avoid using language features that transfer control of the program flow via a jump.
  
• 
  Avoid the use of multiple exit points from a function/procedure/method/subroutine unless it can be shown that the code with multiple exit points is superior.
  
• 
  Avoid multiple entry points to a function/procedure/method/subroutine.
  

6.31.6 Implications for standardization

In future standardization activities, the following items should be considered:

• 
  Languages should support and favor structured programming through their constructs to the extent possible.
  

6.32 Passing Parameters and Return Values [CSJ]

6.32.1 Description of application vulnerability

Nearly every procedural language provides some method of process abstraction permitting decomposition of the flow of control into routines, functions, subprograms, or methods. (For the purpose of this description, the term subprogram will be used.) To have any effect on the computation, the subprogram must change data visible to the calling program. It can do this by changing the value of a non-local variable, changing the value of a parameter, or, in the case of a function, providing a return value. Because different languages use different mechanisms with different semantics for passing parameters, a programmer using an unfamiliar language may obtain unexpected results.

6.32.2 Cross reference

JSF AV Rules: 20, 116
MISRA C 2012: 8.2, 8.3, 8.13, and 17.1-17.3

MISRA C++ 2008: 0-3-2, 7-1-2, 8-4-1, 8-4-2, 8-4-3, and 8-4-4

CERT C guidelines: EXP12-C and DCL33-C

Ada Quality and Style Guide: 5.2 and 8.3

6.32.3 Mechanism of failure

The mechanisms for parameter passing include: call by reference, call by copy, and call by name. The last is so specialized and supported by so few programming languages that it will not be treated in this description.

In call by reference, the calling program passes the addresses of the arguments to the called subprogram. When the subprogram references the corresponding formal parameter, it is actually sharing data with the calling program. If the subprogram changes a formal parameter, then the corresponding actual argument is also changed. If the actual argument is an expression or a constant, then the address of a temporary location is passed to the subprogram; this may be an error in some languages.

In call by copy, the called subprogram does not share data with the calling program. Instead, formal parameters act as local variables. Values are passed between the actual arguments and the formal parameters by copying. Some languages may control changes to formal parameters based on labels such as in, out, or inout. There are three cases to consider: call by value for in parameters; call by result for out parameters and function return values; and call by value-result for inout parameters. For call by value, the calling program evaluates the actual arguments and copies the result to the corresponding formal parameters that are then treated as local variables by the subprogram. For call by result, the values of the locals corresponding to formal parameters are copied to the corresponding actual arguments. For call by value-result, the values are copied in from the actual arguments at the beginning of the subprogram's execution and back out to the actual arguments at its termination.

The obvious disadvantage of call by copy is that extra copy operations are needed and execution time is required to produce the copies. Particularly if parameters represent sizable objects, such as large arrays, the cost of call by copy can be high. For this reason, many languages also provide the call by reference mechanism. The disadvantage of call by reference is that the calling program cannot be assured that the subprogram hasn't changed data that was intended to be unchanged. For example, if an array is passed by reference to a subprogram intended to sum its elements, the subprogram could also change the values of one or more elements of the array. However, some languages enforce the subprogram's access to the shared data based on the labeling of actual arguments with modes—such as in, out, or inout or by constant pointers.

Another problem with call by reference is unintended aliasing. It is possible that the address of one actual argument is the same as another actual argument or that two arguments overlap in storage. A subprogram, assuming the two formal parameters to be distinct, may treat them inappropriately. For example, if one codes a subprogram to swap two values using the exclusive-or method, then a call to swap(x,x) will zero the value of x. Aliasing can also occur between arguments and non-local objects. For example, if a subprogram modifies a non-local object as a side-effect of its execution, referencing that object by a formal parameter will result in aliasing and, possibly, unintended results.

Some languages provide only simple mechanisms for passing data to subprograms, leaving it to the programmer to synthesize appropriate mechanisms. Often, the only available mechanism is to use call by copy to pass small scalar values or pointer values containing addresses of data structures. Of course, the latter amounts to using call by reference with no checking by the language processor. In such cases, subprograms can pass back pointers to anything whatsoever, including data that is corrupted or absent.

Some languages use call by copy for small objects, such as scalars, and call by reference for large objects, such as arrays. The choice of mechanism may even be implementation-defined. Because the two mechanisms produce different results in the presence of aliasing, it is very important to avoid aliasing.

An additional problem may occur if the called subprogram fails to assign a value to a formal parameter that the caller expects as an output from the subprogram. In the case of call by reference, the result may be an uninitialized variable in the calling program. In the case of call by copy, the result may be that a legitimate initialization value provided by the caller is overwritten by an uninitialized value because the called program did not make an assignment to the parameter. This error may be difficult to detect through review because the failure to initialize is hidden in the subprogram.

An additional complication with subprograms occurs when one or more of the arguments are expressions. In such cases, the evaluation of one argument might have side-effects that result in a change to the value of another or unintended aliasing. Implementation choices regarding order of evaluation could affect the result of the computation. This particular problem is described in Side-effects and Order of Evaluation clause [SAM].

6.32.4 Applicable language characteristics

This vulnerability description is intended to be applicable to languages with the following characteristics:

• 
  Languages that provide mechanisms for defining subprograms where the data passes between the calling program and the subprogram via parameters and return values. This includes methods in many popular object-oriented languages.
  

6.32.5 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Use available mechanisms to label parameters as constants or with modes like in, out, or inout.
  
• 
  When a choice of mechanisms is available, pass small simple objects using call by copy.
  
• 
  When a choice of mechanisms is available and the computational cost of copying is tolerable, pass larger objects using call by copy.
  
• 
  When the choice of language or the computational cost of copying forbids using call by copy, then take safeguards to prevent aliasing:
  
  • 
    Minimize side-effects of subprograms on non-local objects; when side-effects are coded, ensure that the affected non-local objects are not passed as parameters using call by reference.
    
  • 
    To avoid unintentional aliasing, avoid using expressions or functions as actual arguments; instead assign the result of the expression to a temporary local and pass the local.
    
  • 
    Utilize tools or other forms of analysis to ensure that non-obvious instances of aliasing are absent.
    
  • 
    Perform reviews or analysis to determine that called subprograms fulfill their responsibilities to assign values to all output parameters.
    

6.32.6 Implications for standardization

In future standardization activities, the following items should be considered:

• 
  Programming language specifications could provide labels—such as in, out, and inout—that control the subprogram’s access to its formal parameters, and enforce the access.