Baseline for Ed 2 of tr 24772


Inadequate language support



Yüklə 0,54 Mb.
səhifə5/54
tarix16.08.2018
ölçüsü0,54 Mb.
#63136
1   2   3   4   5   6   7   8   9   ...   54

5.2.6 Inadequate language support


No language is suitable for every possible application. Furthermore, programmers sometimes do not have the freedom to select the language that is most suitable for the task at hand. In many cases, libraries must be used to supplement the functionality of the language. Then, the library itself becomes a potential source of uncertainty reducing the predictability of execution.

5.3 Sources of unpredictability in language usage

5.3.1 Porting and interoperation


When a program is recompiled using a different compiler, recompiled using different switches, executed with different libraries, executed on a different platform, or even interfaced with different systems, its behaviour will change. Changes result from different choices for unspecified and implementation-defined behaviour, differences in library function, and differences in underlying hardware and operating system support. The problem is far worse if the original programmer chose to use implementation-dependent extensions to the language rather than staying with the standardized language.

5.3.2 Compiler selection and usage


Nearly all software has bugs and compilers are no exception. They should be carefully selected from trusted sources and qualified prior to use. Perhaps less obvious, though, is the use of compiler switches. Different switch settings can result in differences in generated code. A careful selection of settings can improve the predictability of code, for example, a setting that causes the flagging of any usage of an implementation-defined behaviour.

5.4 Top avoidance mechanisms (guidance?)


Each vulnerability listed in sections 6 and 7 provides a set of ways that the vulnerability can be avoided or mitigated. Many of the mitigations and avoidance mechanisms are common. This subclause provides the most most effective and the most common mitigations, together with references to which vulnerabilities they apply. The references are hyperlinked to provide the reader with easy access to those vulnerabilities for rationale and further exploration.

The expectation is that users of this document will develop and use a coding standard based on this document that is tailored to their risk environment.




Number

Recommended avoidance mechanism

References

1

Validate input. Do not make assumptions about the values of parameters. Check parameters for valid ranges and values in the calling and/or called functions before performing any operations.

6.6 7.13

7.18


7.28

2

Where functions return error values, check the return values before processing any other returned data.

6.36

6.60


3

Enable compiler static analysis checking and resolve compiler warnings.

6.8 6.10 6.14 6.15

6.16 6.17 6.18 6.19

6.22 6.25 6.26 6.27

6.29 6.30 6.34 6.36

6.38 6.39 6.47 6.54

6.56 6.57 6.60 6.61

6.62 7.28.


4

Run a static analysis tool to detect anomalies not caught by the compiler.

6.3 6.6 6.7 6.8

6.10 6.14 6.15 6.16

6.17 6.18 6.19 6.22

6.25 6.26 6.27 6.29

6.30 6.34 6.36 6.38

6.39 6.47 6.54 6.56

6.57 6.60 6.61 6.62

7.28


5

Perform explicit range checking when it cannot be shown statically that ranges will be obeyed, when range checking is not provided by the implementation, or if automatic range checking is disabled.

6.6

6.8


6.16

6

Allocate and free memory at the same level of abstraction.

6.14

7

Test constructs that have unspecified behavior for all possible behaviours.

6.24 6.56

8

Make error detection, error reporting, error correction, and recovery an integral part of a system design.

6.36

10

Use only those features of the programming language that enforce a logical structure on the program.

6.31

11

Avoid using features of the language which are not specified to an exact behaviour or that are undefined, implementation-defined or deprecated.

6.55 6.56

6.57 6.58

6.59


12

Avoid using libraries without proper signatures.

6.34

13

Do not modify loop control variables inside the loop body.

6.29

14

Do not perform assignments within Boolean expressions, where possible in the language system.

6.25

15

Do not depend on side-effects of a term in the expression itself.

6.31 6.24 (check)

16

Use names that are clear and visually unambiguous. Be consistent in choosing names.

6.17

17

Use careful programming practice when programming border cases.

6.6 6.29

6.30


18

Be aware of short-circuiting behaviour when expressions with side effects are used on the right side of a Boolean expression such as if the first expression evaluates to false in an and expression, then the remaining expressions, including functions calls, will not be evaluated.

6.24

6.25


19

Avoid fall-through from one case (or switch) statement into the following case statement: if a fall-through is necessary then provide a comment to inform the reader that it is intentional.

6.27

20

Do not use floating-point arithmetic when integers or booleans would suffice, especially for counters associated with program flow, such as loop control variables.

6.4

21

Sanitize, erase or encrypt data that will be visible to others (for example, freed memory, transmitted data).

7.11

7.12



Yüklə 0,54 Mb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9   ...   54




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə