To: WG23 Subject: Draft Fortran Annex From: Dan Nagle Date: 2009 July 21 Draft of the Fortran Annex of the WG23 TR 24772 This Annex provides Fortran-specific advice for the items in clause 6, specifically using Annex F from n0191. DRAFT Language Specific Vulnerability Outline Fortran This Annex provides Fortran-specific advice for the items in clause 6. Each vulnerability is addressed, even if only to indicate that the vulnerability does not apply to Fortran. Fortran.1 Identification of standards ISO/IEC 1539-1 (2010) "Fortran 2008" Fortran.2 General Terminology The Fortran standard specifies the forms of Fortran programs (source code) may take, and the rules for interpreting them. It also specifies the form of input and output files. A processor is a combination of a computing system and the mechanism by which programs are transformed for use on that computing system. The standard does not describe the processor, except that, if the program conforms to the standard then the processor shall interpret the program according to the standard. A requirement expressed in ISO/IEC 1539-1 is a requirement on the program, not the processor, unless explicitly stated otherwise. The processor is limited in its required ability to detect errors to those errors that can be found by reference to the numbered syntax rules and constraints of the standard. A behavior not completely specified by ISO/IEC 1539-1 is said to be processor dependent. Some features from earlier revisions of ISO/IEC 1539-1 are considered redundant and largely unused, and are designated decremental features. The two categories of decremental features are deleted features, which are no longer a part of the standard, and obsolescent features, which are part of the standard, but whose use is discouraged. There is a modern equivalent for every decremental feature that is considered easier to use and more clear in its meaning. A Fortran processor optionally cooperates with one or more companion processors, called coprocessors, that may be compilers of other languages. A processor is its own coprocessor, additional coprocessors may be compilers of other languages. The only requirement is that the other languages allow their data and procedures to be described in terms of C. The actions of routines written in a language other than Fortran are not subject to the rules of Fortran. %%%%% Fortran.3.1 Obscure Language Features [BRS] Fortran.3.1.0 Status and history Original draft - DLN 2009Jul14 - Updated in light of n0202 meeting 11 DLN 2009Jul15 - Updated in light of n0202 meeting 11 in plenary DLN Fortran.3.1.1 Terminology and features : A decremental feature is a feature defined by an earlier revision of the Fortran language, and is considered redundant and largely unused by modern programs. : A deleted feature is a decremental feature that is not specified by the current revision of the standard. : An obsolescent feature is a decremental feature that is specified by the current revision of the standard. Its use is discouraged since a better alternative is specified by the current revision of the standard. : Storage association is the association of two or more data objects that occurs when two or more storage sequences share or are aligned with one or more storage units. : A storage sequence is a sequence of storage units. A storage unit is a numeric storage unit, a character storage unit, a file storage unit, or an unspecified storage unit. : A common block is a block of physical storage. : A common statement specifies blocks of physical storage. : The save attribute specifies that a local data entity retains its definition status between subsequent references to the program unit that declares it. : Intrinsic procedures are procedures specified by the standard. A processor is allowed to extend the set of instrnsic procedures it supports. Fortran.3.1.2 Description of vulnerability An original programmer decades ago may have understood use of a feature whose use was common at the time, but the entirety of effects of some decremental features may not be known to modern programmers. These effects may produce semantic results not in accord with the modern programmer's intentions. They may be beyond the knowledge of modern code reviewers. For example, supplying an initial value in the declaration of a local variable implies that the variable has the save attribute. Also, a common statement may specify more than one common block, and the definition of a common block may be extended by a subsequent common statement in the same program unit. Any of the above situations may be unexpected by a modern programmer. Fortran.3.1.3 Avoiding the vulnerability or mitigating its effects - Use the processor to detect and identify decremental features. All decremental features have modern counterparts that are safer, easier to understand, and more parallel to the semantics of other languages. - Use the processor to detect and identify extensions. The modern standard alternative should be preferred. - Use a tool to detect any of the above. - Avoid the use of decremental features. - Avoid the use of processor extensions, including processor-defined intrinsic procedures. - Supply an external attribute for any name with the external attribute. This will prevent the processor from substituting its own intrinsic of the same signature. - Place the entire definition of one common block entirely within a single statement; one statement should define exactly one common block. - Be aware that an initial value of a variable implies static storage. Fortran.3.1.4 Implications for standardization Future standardization efforts should consider: - Identifying and depreciating features whose use is problematic and where there is a safer and more clear alternative in the modern revisions of the language. Fortran.3.1.5 Bibliography None. %%%%% Fortran.3.2 Unspecified Behaviour [BQF] Fortran.3.2.0 Status and history Original draft - DLN 2009Jul14 - Updated in light of n0202 meeting 11 DLN Fortran.3.2.1 Fortran-specific terminology and features : The use of any form or relation not specified by the Fortran standard is unspecified. The use of any form or relationship given a meaning not specified by the standard is unspecified. Any behaviour not specified by the standard is unspecified behaviour. Fortran.3.2.2 Description of vulnerability A Fortran processor is unconstrained unless the program uses only those forms and relations specified by the Fortran standard, and gives them the meaning described therein. What a processor does with non-standard code is unpredictable. The behavior of non-standard code can change between processors, or between releases of the same processor. It is entirely unpredictable. Fortran.3.2.3 Avoiding the vulnerability or mitigating its effects - Use processor options to detect and report use of non-standard features. - Use more than one processor to obtain diagnostics from more than one source. - Use only intrinsic procedures specified by the standard. Fortran.3.2.4 Implications for standardization in Fortran Future standardization efforts should consider: - Requiring that processors have the ability to detect and report the occurrence within a submitted program unit of character constants used as format specifiers. Fortran.3.2.5 Bibliography None. %%%%% Fortran.3.3 Undefined Behaviour [EWF] Fortran.3.3.0 Status and history Original draft - DLN 2009Jul14 - Updated in light of n0202 meeting 11 DLN This vulnerability is described by Fortran.3.2 Unspecified Behaviour [BQF] described above. %%%%% Fortran.3.4 Implementation-defined Behaviour [FAB] Fortran.3.4.0 Status and history Original draft - DLN 2009Jul14 - Updated in light of n0202 meeting 11 DLN Fortran.3.4.1 Fortran-specific terminology and features : Processor-dependent behaviour is the Fortran term for implementation-defined behaviour. See Annex A.2 of ISO/IEC 1539-1 for a list of processor dependencies. Fortran.3.4.2 Description of vulnerability Different processors may process different processor-dependencies differently. Relying on one behaviour is not guaranteed by the Fortran standard. Reliance on one behaviour where the standard explicitly allows several is not portable, and is liable to change between releases of a single processor, or between different processors. Fortran.3.4.3 Avoiding the vulnerability or mitigating its effects Do not rely on processor dependencies. See Annex A.2 for a complete list. Fortran.3.4.4 Implications for standardization in Fortran Future standardization efforts should consider: - Requiring that processors have the ability to detect and report the occurrence within a submitted program unit of more situations where the appearance of depending upon processor-dependent behaviour occurs. For example, consider requiring that processors have the ability to detect and report the occurrence within a submitted program unit of the appearance of a literal kind value. Fortran.3.4.5 Bibliography None. %%%%% Fortran.3.5 Deprecated Language Features [MEM] Fortran.3.5.0 Status and history Original draft - DLN 2009Jul14 - Updated in light of n0202 meeting 11 DLN Fortran.3.5.1 Fortran-specific terminology and features : A decremental feature is a feature defined by an earlier revision of the Fortran language and is considered redundant and largely unused by modern programs. : A deleted feature is a decremental feature that is not specified by the current revision of the standard. : An obsolescent feature is a decremental feature that is specified by the current revision of the standard. Its use is discouraged since a better alternative is specified by the current revision of the standard. Fortran.3.5.2 Description of vulnerability An original programmer decades ago may have understood use of a feature whose use was common at the time, but the entirety of effects of some decremental features may not be known to modern programmers. These effects may produce semantic results not in accord with the modern programmer's intentions. They may be beyond the knowledge of modern code reviewers. See Annex B of the standard for a complete list. Fortran.3.5.3 Avoiding the vulnerability or mitigating its effects - Do not use decremental features. - Use the processor to detect and identify decremental features; then replace them with a modern synonym. - Use processor options to require adherence to the latest standard. - Use a tool to accomplish any of the above. Fortran.3.5.4 Implications for standardization in Fortran Future standardization efforts should consider: - Identifying and deprecating features whose use is problematic and where there is a safer and more clear alternative in the modern revisions of the language. Fortran.3.5.5 Bibliography None. %%%%% Fortran.3.6 Pre-processor Directives [NMP] Fortran.3.6.0 Status and history Original draft - DLN 2009Jul14 - Updated in light of n0202 meeting 11 DLN The Fortran Standard does not specify a preprocessor. %%%%% Fortran.3.7 Choice of Clear Names [NAI] Fortran.3.7.0 Status and history Original draft - DLN 2009Jul14 - Updated in light of n0202 meeting 11 DLN Fortran.3.7.1 Fortran-specific terminology and features : The processor character set is divided into control characters and graphic characters. The graphic characters are further divided into letters, digits, the underscore, special characters (Table 3.1), and other characters. : When there is no explicit declaration for a name, the implicit type of a variable is the type given by the first letter of its name. Implicit typing may be defeated by including an implicit none statement in a scoping unit. Fortran.3.7.2 Description of vulnerability The set of other characters supported by a processor is processor-dependent. Fortran is a single case language, upper case and lower case must be treated identically by the processor. Use of names differing only in capitalization, intended to be distinct, in fact are not distinct. While some processors have options to preserve case of names, others do not. In any case, using case to distinguish names directly contradicts the standard and should be shunned. While the underscore may be used in names, the number of consecutive underscores is difficult to readily see. Do not use consecutive underscores in a name. Fortran has keywords but no reserved words. Use of a keyword as a name may be possible, but is confusing and should be shunned. Some keywords allow an optional blank, as described in subclause 3.3.2.2, the blanks should always be used. When implicit typing is in effect, a misspelling of a name results in a new variable. Fortran.3.7.3 Avoiding the vulnerability or mitigating its effects - Always use free format so blanks are significant. - Always use the optional blank within a keyword (3.3.2.2). - Do not distinguish names by case only. - Do not use consecutive underscores in a name. - Do not use keywords as names. - Always use implicit none to disable implicit typing. Fortran.3.7.4 Implications for standardization in Fortran Future standardization efforts should consider: - Requiring that processors have the ability to detect and report the occurrence within a submitted program unit of names appearing to differ only in case, or that have consecutive underscores. - Requiring that processors have the ability to detect and report the occurrence within a submitted program unit of names indistinguishable from keywords. Fortran.3.7.5 Bibliography None. %%%%% Fortran.3.8 Choice of Filenames and other External Identifiers [AJN] Fortran.3.8.0 Status and history Original draft - DLN 2009Jul16 Upgrade to new format - DLN Fortran.3.8.1 Language-specific terminology : Character assignment to a fixed length LHS has a truncate or blank fill semantic. This does not apply to allocatable characters, where the length is adjusted as needed. Fortran.3.8.2 Description of vulnerability Filenames appearing as input to OPEN and INQUIRE statements, and character values appearing as input in references to the GET_ENVIRONMENT_VARIABLE intrinsic and the EXECUTE_COMMAND_LINE intrinsic, have trailing blanks removed. Any filename, environment variable name, or name specified on an INCLUDE line is processor-dependent. This is a result of the historic use of static length characters, where a character assignment might leave trailing blanks. Thus, trailing blanks are not used externally. Fortran.3.8.3 Avoiding the vulnerability or mitigating its effects - Do not attempt to distinguish external names by trailing blanks. Fortran.3.8.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing a mechanism whereby trailing blanks may be used externally. Fortran.3.8.5 Bibliography None. %%%%% Fortran.3.9 Unused Variable [XYR] Fortran.3.9.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.9.1 Language-specific terminology : When there is no explicit declaration for a name, the implicit type of a variable is the type given by the first letter of its name. Implicit typing may be defeated by including an implicit none statement in a scoping unit. Fortran.3.9.2 Description of vulnerability When implicit typing is used, a simple spelling error may introduce a new variable, that has a name similar to the intended name. Yet the new variable is unused. Fortran.3.9.3 Avoiding the vulnerability or mitigating its effects Use IMPLICIT NONE to require explicit declarations. Use any available processor options to report unused variables. Do not use common blocks, as the common may legitimately contain names of variables unused in one subprogram. Use ONLY clauses on USE statements to indicate the names being accessed by use association. Use rename clauses to avoid name collisions. Fortran.3.9.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing that processors have the ability to detect and report the occurrence within a submitted program unit of an unused variable. - Providing that processors have the ability to detect and report the occurrence within a submitted program unit of any variable given an implicit type. Fortran.3.9.5 Bibliography None. %%%%% Fortran.3.10 Identifier Name Reuse [YOW] Fortran.3.10.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.10.1 Language-specific terminology : The processor character set is divided into control characters and graphic characters. The graphic characters are further divided into letters, digits, the underscore, special characters (Table 3.1), and other characters. : The implicit type of a variable is the type given by the first letter of its name. Implicit typing may be defeated by including an implicit none statement in a scoping unit. : Association between a name in a contained scope, and the host scope, or between a submodule and the module. Fortran.3.10.2 Description of vulnerability Fortran names may contain up to 63 characters (letters, digits, and the underscore), all of which are significant. Thus, a name is either illegal or all its characters are used. Internal procedures access the names available in their hosts. Module procedures access the names available in their module. Submodules access the names of the parent module. Blocks access the names available in their host. Fortran.3.10.3 Avoiding the vulnerability or mitigating its effects Do not use BLOCKS. Do not use nested declarations in DO CONCURRENT blocks. Use an ONLY clause on all USE statements. Check names in nested procedures. Prefer placing subprograms in modules rather than as internal procedures. Use different modules for types and data, and for procedures. Fortran.3.10.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing that processors have the ability to detect and report the occurrence within a submitted program unit of an illegal name. - Providing that processors have the ability to detect and report the occurrence within a submitted program unit of any instance where a name in a nested scope prevents access to a name in the host scope. - Adding a means to control host association. - Decrementing BLOCKS and declarations in DO CONCURRENT statements. Fortran.3.10.5 Bibliography None. %%%%% Fortran.3.11 Type System [IHN] Fortran.3.11.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.11.1 Language-specific terminology : A type defined by the standard is an intrinsic type. : A type defined by the programmer is a derived type. Some derived types are named in standard defined modules (they have private components). Fortran.3.11.2 Description of vulnerability Fortran promotes operands in expressions from smaller to larger within a numeric type, and among types, from integer to real to complex. There is no automatic conversion between derived types and intrinsic types. There is no automatic conversion between two derived types, except for the case of extended derived types (where the child type may be assigned to the parent type). Fortran expressions are evaluated without regard to context; the type of an expression is converted as needed to the type of the designator receiving the value. Fortran.3.11.3 Avoiding the vulnerability or mitigating its effects - Explicitly convert expressions as needed. - Provide defined assignment as needed. Fortran.3.11.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing a capability to report, forbid, or control automatic conversions. - Providing an inquiry intrinsic to provide the largest integer a real kind is capable of representing exactly. Fortran.3.11.5 Bibliography None. %%%%% Fortran.3.12 Bit Representations [STR] Fortran.3.12.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.12.1 Language-specific terminology : Storage association is the association of two or more data objects that occurs when two or more storage sequences share or are aligned with one or more storage units. : A storage sequence is a sequence of storage units. A storage unit is a numeric storage unit, a character storage unit, a file storage unit, or an unspecified storage unit. Fortran.3.12.2 Description of vulnerability A bit representation might be made visible when the same storage location in a storage sequence has names with different types. This can occur when a common block has different names in different scopes, or when an equivalence has names of different types for the same location. Also, the TRANSFER intrinsic copies bits between variables without regard for their types. Misuse of the Interoperability with C features of Fortran may result in a violation of the Fortran type system. Fortran.3.12.3 Avoiding the vulnerability or mitigating its effects - Always use the same definition for a common block in every scoping unit. Better, convert common blocks to modules. Use renames to retain previous names as needed. - Keep the same type for all variables in an equivalence set. - Do not use TRANSFER. - Ensure type consistency when passing pointers to coprocessor routines. Fortran.3.12.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing that processors have the ability to detect and report the occurrence within a submitted program unit of storage locations with more then one type, and report the use of the TRANSFER intrinsic. Fortran.3.12.5 Bibliography None. %%%%% Fortran.3.13 Floating-point Arithmetic [PLF] Fortran.3.13.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.13.1 Language-specific terminology : An inquiry intrinsic is an intrinsic function that returns information about the model number supported by its argument. Fortran.3.13.2 Description of application vulnerability A floating point number is of type real. There are several (at least two) kinds of type real supported by any processor. The type kind values parameterize the precision and range (of exponent) supported. There is a complex kind for every real kind. Possibly distinct type kind values are available via the IEEE intrinsic modules. Fortran.3.13.3 Avoiding the vulnerability or mitigating its effects Where precise control of floating point operations is required, use the IEEE intrinsic modules, and the values and procedures therein. Use trusted libraries to perform common operations (such as linear algebra, Fourier transforms, minimax problems, and so on). Fortran.3.13.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing that processors have the ability to detect and report the occurrence within a submitted program unit of tests for floating point equality. Fortran.3.13.5 Bibliography None. %%%%% Fortran.3.14 Enumerator Issues [CCB] Fortran.3.14.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.14.1 Language-specific terminology None. Fortran.3.14.2 Description of vulnerability The Fortran enumerator type is designed solely for interoperability with the C enumerator type, and should not be used for other purposes. Fortran.3.14.3 Avoiding the vulnerability or mitigating its effects - Do not use enumerators for purposes other than interoperability with C. Fortran.3.14.4 Implications for standardization in Fortran Future standardization efforts should consider: - Defining a standard enumerator type for uses beyond interoperability with C. Fortran.3.14.5 Bibliography None. %%%%% Fortran.3.15 Numeric Conversion Errors [FLC] Fortran.3.15.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.15.1 Language-specific terminology None. Fortran.3.15.2 Description of vulnerability As per Clause 6. Fortran.3.15.3 Avoiding the vulnerability or mitigating its effects As per Clause 6. Fortran.3.15.4 Implications for standardization in Fortran Future standardization efforts should consider: - Adding a requirement that processors have the ability to detect and report conversions that might result in loss of data. - Adding an inquiry intrinsic to report the largest integer that a real type can represent exactly. Fortran.3.15.5 Bibliography None. %%%%% Fortran.3.16 String Termination [CJM] Fortran.3.16.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran does not use a string termination code. %%%%% Fortran.3.17 Boundary Beginning Violation [XYX] Fortran.3.17.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.17.1 Language-specific terminology : An extent of an array is one dimension, it has an arbitrary upper bound and lower bound. : Rank is the number of dimensions of an array. : The upper bound is the largest valid index of an extent. : The lower bound is the smallest valid index of an extent. : Array assignment allows one array to be assigned to another. Fortran.3.17.2 Description of vulnerability An array access outside the bounds of any extent is undefined, its effects are unpredictable. Fortran.3.17.3 Avoiding the vulnerability or mitigating its effects - Use whole array assignment, operations, and intrinsics where possible. - Use inquiry intrinsics to determine upper and lower bounds. - Choose upper and lower bounds that naturally describe the problem. - Use assumed shape arrays when passing array arguments. - Use allocatable, automatic, or fixed shape local arrays. Fortran.3.17.4 Implications for standardization in Fortran None. Fortran.3.17.5 Bibliography None. %%%%% Fortran.3.18 Unchecked Array Indexing [XYZ] Fortran.3.18.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN This is covered by [XYX]. %%%%% Fortran.3.19 Unchecked Array Copying [XYW] Fortran.3.19.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN This is covered by [XYX]. %%%%% Fortran.3.20 Buffer Overflow [XZB] Fortran.3.20.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN This is covered by [XYX]. %%%%% Fortran.3.21 Pointer Casting and Pointer Type Changes [HFC] Fortran.3.21.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN A Fortran pointer cannot change type. %%%%% Fortran.3.22 Pointer Arithmetic [RVG] Fortran.3.22.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN There is no arithmetic on pointers. %%%%% Fortran.3.23 Null Pointer Dereference [XYH] Fortran.3.23.0 Status and history Original draft - DLN 2009Jul17 Upgrade to new format - DLN Fortran.3.23.1 Language-specific terminology : Target is an attribute of a storage location that can be associated with a pointer. The target is the actual storage location. : Pointer is an attribute of a name that can be associated with a target. : Allocatable is an attribute of a name that can be associated with an anonymous target. Fortran.3.23.2 Description of application vulnerability A name with the pointer attribute must be associated with a target in order to be used. A name with the allocatable attribute must be allocated in order to be used. Fortran.3.23.3 Avoiding the vulnerability or mitigating its effects - Use the associated intrinsic to ensure that a pointer is associated with a target before referencing the name with the pointer attribute. - Use the allocated intrinsic to ensure that an allocatable is allocated before referencing the name. Fortran.3.23.4 Implications for standardization in Fortran Future standardization efforts should consider: - Adding new dummy argument intents to cover all cases of pointer can change, or the target can change. Fortran.3.23.5 Bibliography None. %%%%% Fortran.3.24 Dangling Reference to Heap [XYK] Fortran.3.24.0 Status and history Original draft - DLN 2009Jul18 Upgrade to new format - DLN Fortran.3.24.1 Language-specific terminology : Allocatable is an attribute of a name that can be associated with an anonymous target. : The save attribute specifies that a local data entity retains its definition status between subsequent references to the program unit that declares it. Fortran.3.24.2 Description of vulnerability Fortran does not specify how variables are stored. Many implementations will store allocatable variables on the heap. Fortran.3.24.3 Avoiding the vulnerability or mitigating its effects Apply the SAVE attribute to allocatable local variables whenever a pointer defined outside the procedure is pointer assigned to the variable. Fortran.3.24.4 Implications for standardization in Fortran Future standardization efforts should consider: None. Fortran.3.24.5 Bibliography None. %%%%% Fortran.3.25 Templates and Generics [SYM] Fortran.3.25.0 Status and history Original draft - DLN 2009Jul18 Upgrade to new format - DLN This subclause does not apply to Fortran. %%%%% Fortran.3.26 Inheritance [RIP] Fortran.3.26.0 Status and history Original draft - DLN 2009Jul18 Upgrade to new format - DLN Fortran.3.26.1 Language-specific terminology : A child type derived from a parent type extends the parent type. Fortran.3.26.2 Description of vulnerability Fortran.3.26.3 Avoiding the vulnerability or mitigating its effects - Use the nonoverridable attribute whenever possible. Fortran.3.26.4 Implications for standardization in Fortran Future standardization efforts should consider: - Adding class invariants. Fortran.3.26.5 Bibliography None. %%%%% Fortran.3.27 Initialization of Variables [LAV] Fortran.3.27.0 Status and history Original draft - DLN 2009Jul19 Upgrade to new format - DLN Fortran.3.27.1 Language-specific terminology : The save attribute specifies that a local data entity retains its definition status between subsequent references to the program unit that declares it. Fortran.3.27.2 Description of vulnerability Specifying an initial value to a procedure local variable applies the save attribute. Fortran.3.27.3 Avoiding the vulnerability or mitigating its effects Use executable statements to supply initial values to procedure local variables. Fortran.3.27.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing a way to declare an initial value for a variable every time the scope in which it is declared is entered without forcing static storage. Fortran.3.27.5 Bibliography None. %%%%% Fortran.3.28 Wrap-around Error [XYY] Fortran.3.28.0 Status and history Original draft - DLN 2009Jul19 Upgrade to new format - DLN Fortran.3.28.1 Language-specific terminology : The processor-supplied model of the numeric representation supported by the processor. Its parameters are available via the inquiry intrinsics. Fortran.3.28.2 Description of application vulnerability Fortran provides no description of wrap-around errors, nor any way to detect them. Fortran.3.28.3 Avoiding the vulnerability or mitigating its effects - Do not use the same variables for bit operations and for arithmetic; instead, use separate variables and check values upon conversion. Fortran.3.28.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing a separate type for bit operations. - Providing an intrinsic to detect and/or predict when an integer operation will/has produce a wrap-around error. Fortran.3.28.5 Bibliography None. %%%%% Fortran.3.29 Sign Extension Error [XZI] Fortran.3.29.0 Status and history Original draft - DLN 2009Jul19 Upgrade to new format - DLN Fortran.3.29.1 Language-specific terminology Fortran does not have unsigned data types. Fortran.3.29.2 Description of vulnerability Fortran.3.29.3 Avoiding the vulnerability or mitigating its effects - Choose the particular bit shift intrinsic as appropriate. - Understand the bit model. Fortran.3.29.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing a separate type for bit operations. Fortran.3.29.5 Bibliography None. %%%%% Fortran.3.30 Operator Precedence/Order of Evaluation [JCW] Fortran.3.30.0 Status and history Original draft - DLN 2009Jul19 Upgrade to new format - DLN Assignment is not an operator in Fortran. Bit operations are intrinsic functions, so precedence is clear. %%%%% Fortran.3.31 Side-effects and Order of Evaluation [SAM] Fortran.3.31.0 Status and history Original draft - DLN 2009Jul20 Upgrade to new format - DLN Fortran.3.31.1 Language-specific terminology : An expression represents either a data reference or a computation, and its value is either a scalar or an array. An expression is formed from operands, operators, and parentheses. Fortran.3.31.2 Description of vulnerability A Fortran processor may evaluate an expression in any order it chooses. A Fortran processor need not evaluate any part of an expression not needed to compute the value of the expression. Side effects of functions contributing to such portions of expressions are processor-dependent, and any values associated with such problematic evaluation are undefined. Fortran.3.31.3 Avoiding the vulnerability or mitigating its effects - Do not put functions in expressions where they might not be evaluated if the function has side effects. - Prefer to use pure functions where that will achieve the programming objective. - Use parenthesis and/or partial result variables to control the order of evaluation of expressions. Fortran.3.31.4 Implications for standardization in Fortran Future standardization efforts should consider: - Adding an attribute to control function evaluation in expressions. Fortran.3.31.5 Bibliography None. %%%%% Fortran.3.32 Likely Incorrect Expression [KOA] Fortran.3.32.0 Status and history Original draft - DLN 2009Jul20 Upgrade to new format - DLN This is covered by [SAM] above. %%%%% Fortran.3.33 Dead and Deactivated Code [XYQ] Fortran.3.33.0 Status and history Original draft - DLN 2009Jul20 Upgrade to new format - DLN Fortran.3.33.1 Language-specific terminology Fortran.3.33.2 Description of vulnerability Fortran.3.33.3 Avoiding the vulnerability or mitigating its effects Fortran.3.33.4 Implications for standardization in Fortran Future standardization efforts should consider: - Requiring processors to detect and report the occurrence within a submitted program unit of unreachable code. Fortran.3.33.5 Bibliography None. %%%%% Fortran.3.34 Switch Statements and Static Analysis [CLL] Fortran.3.34.0 Status and history Original draft - DLN 2009Jul20 Upgrade to new format - DLN Fortran.3.34.1 Language-specific terminology Fortran.3.34.2 Description of vulnerability Fortran.3.34.3 Avoiding the vulnerability or mitigating its effects Fortran.3.34.4 Implications for standardization in Fortran Future standardization efforts should consider: - Requiring processors to have the ability to detect and report the occurrence within a submitted program unit where a select case construct does not cover all cases. - Requiring processors to have the ability to detect and report the occurrence within a submitted program unit where a select case construct contains a default block. Fortran.3.34.5 Bibliography None. %%%%% Fortran.3.35 Demarcation of Control Flow [EOJ] Fortran.3.35.0 Status and history Original draft - DLN 2009Jul20 Upgrade to new format - DLN Fortran.3.35.1 Language-specific terminology None. Fortran.3.35.2 Description of vulnerability A go to to the terminal statement of a non-block do construct may be difficult to understand, especially when the constructs are nested. Fortran.3.35.3 Avoiding the vulnerability or mitigating its effects Note that the non-block form of the DO construct is a decremental feature, and as such, it should not be used. Use the block form of the DO loop. Fortran.3.35.4 Implications for standardization in Fortran Future standardization efforts should consider: - Deleting the non-block form of the do construct. Fortran.3.35.5 Bibliography None. %%%%% Fortran.3.36 Loop Control Variables [TEX] Fortran.3.36.0 Status and history Original draft - DLN 2009Jul20 Upgrade to new format - DLN Fortran.3.36.1 Language-specific terminology None. Fortran.3.36.2 Description of vulnerability It is not possible to modify the loop control variable of a DO loop in any way that the processor can detect. If the loop control variable is passed to a procedure, the processor might not be able to detect violations. Fortran.3.36.2 Description of vulnerability Fortran.3.36.3 Avoiding the vulnerability or mitigating its effects - Use explicit interfaces for all routines called from within loops, pass the loop variable only to intent in arguments. Fortran.3.36.4 Implications for standardization in Fortran Future standardization efforts should consider: - Requiring an option that all procedures called with loop variables as arguments to have explicit interface and argument intents, so the dummy argument receiving the loop control variable can be checked to be intent in. Fortran.3.36.5 Bibliography None. %%%%% Fortran.3.37 Off-by-one Error [XZH] Fortran.3.37.0 Status and history Original draft - DLN 2009Jul20 Upgrade to new format - DLN Fortran.3.37.1 Language-specific terminology None. Fortran.3.37.2 Description of vulnerability Fortran.3.37.4 Avoiding the vulnerability or mitigating its effects - Be clear about < versus <= and > versus >= operators. - Use inquiry intrinsics to determine the upper and lower bounds of array extents. Fortran.3.37.4 Implications for standardization in Fortran Future standardization efforts should consider: Fortran.3.37.5 Bibliography None. %%%%% Fortran.3.38 Structured Programming [EWD] Fortran.3.38.0 Status and history Original draft - DLN 2009Jul20 Upgrade to new format - DLN Fortran.3.38.1 Language-specific terminology : Alternate return is a means for a subroutine to return to a point in the caller other than the immediately following the point of reference. Fortran.3.38.2 Description of vulnerability Alternate returns, and branches on error or end conditions on input/output statements, are unstructured. Fortran.3.38.3 Avoiding the vulnerability or mitigating its effects - Do not use alternate returns. - Do not use branches from input/output statements when status (error or end) conditions occur. Fortran.3.38.4 Implications for standardization in Fortran Future standardization efforts should consider: - Adding an option to forbid branching from input/output statements, and alternate returns from subprograms. Fortran.3.38.5 Bibliography None. %%%%% Fortran.3.39 Passing Parameters and Return Values [CSJ] Fortran.3.39.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.39.1 Language-specific terminology : The dummy argument is the name of a procedure argument local to the procedure. : The actual argument is the data entity passed to the procedure when it is referenced. : An argument intent is an attribute specifying what actions may be made of a dummy argument. Fortran.3.39.2 Description of application vulnerability Fortran does not specify a mechanism for passing values into or out of a subroutine. This is governed by argument association rules, together with argument intents and the optional attribute. Fortran.3.39.3 Avoiding the vulnerability or mitigating its effects Use argument intents. Fortran.3.39.4 Implications for standardization in Fortran Future standardization efforts should consider: - Adding a more complete set of argument intents, to cover all cases including pointers to constants versus constant pointers. Fortran.3.39.5 Bibliography None. %%%%% Fortran.3.40 Dangling References to Stack Frames [DCM] Fortran.3.40.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.40.1 Language-specific terminology : : : Fortran.3.40.2 Description of vulnerability Fortran.3.40.3 Avoiding the vulnerability or mitigating its effects - Do not assign local targets to pointers whose longevity is longer than the function's execution. Fortran.3.40.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing that processors shall have the ability to detect and report the occurrence within a submitted program unit where pointers declared outside a procedure are pointer assigned to procedure local targets. Fortran.3.40.5 Bibliography None. %%%%% Fortran.3.41 Subprogram Signature Mismatch [OTR] Fortran.3.41.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.41.1 Language-specific terminology : Fortran.3.41.2 Description of vulnerability Fortran.3.41.3 Avoiding the vulnerability or mitigating its effects - Use modules to package procedures so they will have explicit interfaces. - Use interface bodies to describe external procedures, these might be generated automatically by a tool, or by the processor. Fortran.3.41.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing that processors shall have the ability to require explicit interfaces for all procedures. Fortran.3.41.5 Bibliography None. %%%%% Fortran.3.42 Recursion [GDL] Fortran.3.42.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.42.1 Language-specific terminology Fortran.3.42.2 Description of vulnerability Fortran.3.42.3 Avoiding the vulnerability or mitigating its effects Fortran.3.42.4 Implications for standardization in Fortran Future standardization efforts should consider: Fortran.3.42.5 Bibliography None. %%%%% Fortran.3.43 Returning Error Status [NZN] Fortran.3.43.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.43.1 Language-specific terminology Fortran.3.43.2 Description of vulnerability Fortran.3.43.3 Avoiding the vulnerability or mitigating its effects - Always check the STAT= or IOSTAT= specifier as appropriate. Fortran.3.43.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing that processors shall have the ability to require all statements supporting a STAT= or IOSTAT= specifier to have one present on each occurrence. - Providing that no statement would have a end= or err= specifier. Fortran.3.43.5 Bibliography None. %%%%% Fortran.3.44 Termination Strategy [REU] Fortran.3.44.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.44.1 Language-specific terminology Fortran.3.44.2 Description of vulnerability Fortran.3.44.3 Avoiding the vulnerability or mitigating its effects - Understand and use ALL STOP, STOP and SYNC IMAGES correctly. Fortran.3.44.4 Implications for standardization in Fortran Future standardization efforts should consider: Fortran.3.44.5 Bibliography None. %%%%% Fortran.3.45 Extra Intrinsics [LRM] Fortran.3.45.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.45.1 Language-specific terminology Fortran.3.45.2 Description of vulnerability Fortran.3.45.3 Avoiding the vulnerability or mitigating its effects - Give all external names the external attribute, or better, an explicit interface. Fortran.3.45.4 Implications for standardization in Fortran Future standardization efforts should consider: Fortran.3.45.5 Bibliography None. %%%%% Fortran.3.46 Type-breaking Reinterpretation of Data [AMV] Fortran.3.46.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.46.1 Language-specific terminology Fortran.3.46.2 Description of vulnerability Fortran.3.46.3 Avoiding the vulnerability or mitigating its effects - Do not rely on different names with different types in storage sequences. - Do not use TRANSFER. - Do not cause storage association of objects of different type by using common or equivalence. Fortran.3.46.4 Implications for standardization in Fortran Future standardization efforts should consider: - Requiring processors to detect and report when type breaking reuse of bits occurs. Fortran.3.46.5 Bibliography None. %%%%% Fortran.3.47 Memory Leak [XYL] Fortran.3.47.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.47.1 Language-specific terminology Fortran.3.47.2 Description of vulnerability Fortran.3.47.3 Avoiding the vulnerability or mitigating its effects - Use allocatable or automatic variables in local procedures. - Do not apply the SAVE attribute. Fortran.3.47.4 Implications for standardization in Fortran Future standardization efforts should consider: Fortran.3.47.5 Bibliography None. %%%%% Fortran.3.48 Argument Passing to Library Functions [TRJ] Fortran.3.48.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.48.1 Language-specific terminology Fortran.3.48.2 Description of vulnerability Fortran.3.48.3 Avoiding the vulnerability or mitigating its effects - Use explicit interfaces for libraries. - Use tools, if needed, to create interfaces for libraries. Fortran.3.48.4 Implications for standardization in Fortran Future standardization efforts should consider: Fortran.3.48.5 Bibliography None. %%%%% Fortran.3.49 Dynamically-linked Code and Self-modifying Code [NYY] Fortran.3.49.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.49.1 Language-specific terminology Fortran.3.49.2 Description of vulnerability Fortran.3.49.3 Avoiding the vulnerability or mitigating its effects Fortran.3.49.4 Implications for standardization in Fortran Future standardization efforts should consider: Fortran.3.49.5 Bibliography None. %%%%% Fortran.3.50 Library Signature [NSQ] Fortran.3.50.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.50.1 Language-specific terminology Fortran.3.50.2 Description of vulnerability Fortran.3.50.3 Avoiding the vulnerability or mitigating its effects - Use explicit interfaces for libraries. - Use tools, if needed, to create interfaces for libraries. Fortran.3.50.4 Implications for standardization in Fortran Future standardization efforts should consider: Fortran.3.50.5 Bibliography None. %%%%% Fortran.3.51 Unanticipated Exceptions from Library Routines [HJW] Fortran.3.51.0 Status and history Original draft - DLN 2009Jul21 Upgrade to new format - DLN Fortran.3.51.1 Language-specific terminology Fortran.3.51.2 Description of vulnerability Fortran.3.51.3 Avoiding the vulnerability or mitigating its effects - Use explicit interfaces for libraries. - Use tools, if needed, to create interfaces for libraries. Fortran.3.51.4 Implications for standardization in Fortran Future standardization efforts should consider: - Providing a way to handle exceptions. Fortran.3.51.5 Bibliography None.