ISO/IEC TR 24772:2010

TECHNICAL ISO/IEC
REPORT TR
First edition
2010-10-01
Information technology — Programming
languages — Guidance to avoiding
vulnerabilities in programming languages
through language selection and use
Technologies de l'information — Langages de programmation —
Conduite pour éviter les vulnérabilités dans les langages de
programmation à travers la sélection et l'usage de la langue

Reference number
©
ISO/IEC 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2010 – All rights reserved

ISO/IEC TR 24772:2010(E)
Contents  Page
Foreword . vi
Introduction . vii
1  Scope . 1
2.  Normative references . 1
3  Terms and definitions, symbols and conventions . 1
3.1   Terms and definitions, symbols and conventions . 1
3.2  Symbols and conventions . 3
4.  Basic Concepts . 4
4.1  Not in Scope . 4
4.2   Approach . 4
4.3  Intended Audience . 4
4.4  How to Use This Document . 5
5  Vulnerability issues . 8
5.1   Issues arising from incomplete or evolving language specifications . 8
5.2   Issues arising from human cognitive limitations . 11
5.3   Issues arising from a lack of predictable execution . 12
5.4   Issues arising from the lack of portability and interoperability . 12
5.5   Issues arising from inadequate language intrinsic support . 13
5.6   Issues arising from language features prone to erroneous use . 13
6.  Programming Language Vulnerabilities . 14
6.1   General . 14
6.2   Obscure Language Features [BRS] . 14
6.3   Unspecified Behaviour [BQF] . 15
6.4   Undefined Behaviour [EWF] . 17
6.5   Implementation‐defined Behaviour [FAB] . 18
6.6   Deprecated Language Features [MEM] . 20
6.7   Pre‐processor Directives [NMP] . 21
6.8   Choice of Clear Names [NAI] . 23
6.9   Choice of Filenames and other External Identifiers [AJN] . 25
6.10  Unused Variable  [XYR] . 26
6.11  Identifier Name Reuse [YOW] . 27
6.12  Namespace Issues [BJL] . 30
6.13  Type System [IHN] . 31
6.14  Bit Representations [STR] . 34
6.15  Floating‐point Arithmetic [PLF] . 35
6.16  Enumerator Issues [CCB] . 38
6.17  Numeric Conversion Errors [FLC] . 40
© ISO/IEC 2010 – All rights reserved  iii

ISO/IEC TR 24772:2010(E)
6.18  String Termination [CJM] . 42
6.19  Boundary Beginning Violation  [XYX] . 43
6.20  Unchecked Array Indexing  [XYZ] . 44
6.21  Unchecked Array Copying [XYW] . 46
6.22  Buffer Overflow [XZB] . 47
6.23  Pointer Casting and Pointer Type Changes [HFC] . 49
6.24  Pointer Arithmetic [RVG] . 50
6.25  Null Pointer Dereference [XYH] . 51
6.26  Dangling Reference to Heap [XYK] . 52
6.27  Templates and Generics [SYM] . 54
6.28  Inheritance [RIP] . 56
6.29  Initialization of Variables [LAV] . 57
6.30  Wrap‐around Error [XYY] . 59
6.31  Sign Extension Error [XZI] . 60
6.32  Operator Precedence/Order of Evaluation [JCW] . 61
6.33  Side‐effects and Order of Evaluation [SAM] . 63
6.34  Likely Incorrect Expression [KOA] . 64
6.35  Dead and Deactivated Code [XYQ] . 66
6.36  Switch Statements and Static Analysis [CLL] . 68
6.37  Demarcation of Control Flow [EOJ] . 69
6.38  Loop Control Variables [TEX] . 70
6.39  Off‐by‐one Error  [XZH] . 71
6.40  Structured Programming [EWD] . 73
6.41  Passing Parameters and Return Values [CSJ] . 74
6.42  Dangling References to Stack Frames  [DCM] . 77
6.43  Subprogram Signature Mismatch [OTR] . 79
6.44  Recursion [GDL] . 80
6.45  Returning Error Status [NZN] . 81
6.46  Termination Strategy [REU] . 84
6.47  Extra Intrinsics [LRM] . 85
6.48  Type‐breaking Reinterpretation of Data [AMV] . 87
6.49  Memory Leak [XYL] . 89
6.50  Argument Passing to Library Functions [TRJ] . 90
6.51  Dynamically‐linked Code and Self‐modifying Code [NYY] . 91
6.52  Library Signature [NSQ] . 92
6.53  Unanticipated Exceptions from Library Routines [HJW] . 93
7.  Application Vulnerabilities . 95
7.1  Adherence to Least Privilege  [XYN] . 95
7.2  Privilege Sandbox Issues [XYO] . 95
7.3  Executing or Loading Untrusted Code  [XYS] . 97
7.4  Unspecified Functionality  [BVQ] . 98
7.5   Distinguished Values in Data Types [KLK] . 99
7.6  Memory Locking  [XZX] . 100
iv  © ISO/IEC 2010 – All rights reserved

ISO/IEC TR 24772:2010(E)
7.7   Resource Exhaustion [XZP] . 101
7.8  Injection [RST] . 102
7.9  Cross‐site Scripting  [XYT] . 105
7.10  Unquoted Search Path or Element  [XZQ] . 108
7.11  Improperly Verified Signature  [XZR] . 108
7.12  Discrepancy Information Leak  [XZL] . 109
7.13  Sensitive Information Uncleared Before Release [XZK] . 110
7.14  Path Traversal [EWR] . 111
7.15  Missing Required Cryptographic Step [XZS] . 113
7.16  Insufficiently Protected Credentials [XYM] . 113
7.17  Missing or Inconsistent Access Control [XZN] . 114
7.18  Authentication Logic Error [XZO] . 115
7.19  Hard‐coded Password [XYP] . 117
Annex A (informative) Guideline Selection Process . 118
A.1   Selection Process . 118
A.2   Cost/Benefit Analysis . 118
A.3   Documenting of the selection process . 119
Annex B (informative) Template for use in proposing programming language vulnerabilities . 120
B.1   6.  [] . 120
Annex C (informative) Template for use in proposing application vulnerabilities . 122
C.1   7.  [] . 122
Annex D (informative) Vulnerability Outline and List . 123
D.1   Vulnerability Outline . 123
D.2   Vulnerability List . 125
Annex E (informative) Language Specific Vulnerability Template . 127
E.1  .1 Identification of standards . 127
E.2  .2 General terminology and concepts . 127
E.3  .  [<3 letter tag>] . 127
Bibliography . 129

© ISO/IEC 2010 – All rights reserved  v

ISO/IEC TR 24772:2010(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, when the joint technical committee has collected data of a different kind from
that which is normally published as an International Standard (“state of the art”, for example), it may decide to
publish a Technical Report. A Technical Report is entirely informative in nature and shall be subject to review
every five years in the same manner as an International Standard.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 24772 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 22, Programming languages, their environments and system software interfaces.
vi  © ISO/IEC 2010 – All rights reserved

ISO/IEC TR 24772:2010(E)
Introduction
All programming languages contain constructs that are incompletely specified, exhibit undefined behaviour,
are implementation‐dependent, or are difficult to use correctly. The use of those constructs may therefore
give rise to vulnerabilities, as a result of which, software programs can execute differently than intended by
the writer.    In some cases, these vulnerabilities can compromise the safety of a system or be exploited by
attackers to compromise the security or privacy of a system.
This Technical Report is intended to provide guidance spanning multiple programming languages, so that
application developers will be better able to avoid the programming constructs that lead to vulnerabilities in
software written in their chosen language and their attendant consequences.  This guidance can also be
used by developers to select source code evaluation tools that can discover and eliminate some constructs
that could lead to vulnerabilities in their software or to select a programming language that avoids
anticipated problems.
It should be noted that this Technical Report is inherently incomplete. It is not possible to provide a
complete list of programming language vulnerabilities because new weaknesses are discovered continually.
Any such report can only describe those that have been found, characterized, and determined to have
sufficient probability and consequence.
Furthermore, to focus its limited resources, the working group developing this report decided to defer
comprehensive treatment of several subject areas until future editions of the report. These subject areas
include:
 Object‐oriented language features (Although some simple issues related to inheritance are
described in RIP)
 Concurrency
 Numerical analysis (although some simple items regarding the use of floating point are described in
PLF)
 Scripting languages
 Inter‐language operability
 Language‐specific annexes
© ISO/IEC 2010 – All rights reserved  vii

Technical Report  ISO/IEC TR 24772:2010(E)

Information technology — Programming languages —
Guidance to avoiding vulnerabilities in programming languages
through language selection and use
1  Scope
This Technical Report specifies software programming language vulnerabilities to be avoided in the development
of systems where assured behaviour is required for security, safety, mission critical and business critical software.
In general, this guidance is applicable to the software developed, reviewed, or maintained for any application.
Vulnerabilities are described in a generic manner that is applicable to a broad range of programming languages.
2.  Normative references
The following referenced documents are indispensable for the application of this document.  For dated
references, only the edition cited applies.  For undated references, the latest edition of the referenced document
(including any amendments) applies.
ISO/IEC 80000–2:2009, Quantities and units — Part 2: Mathematical signs and symbols to be use in the natural
sciences and technology
ISO/IEC 2382–1:1993, Information technology — Vocabulary — Part 1: Fundamental terms
3  Terms and definitions, symbols and conventions
3.1   Terms and definitions, symbols and conventions
For the purposes of this document, the terms and definitions given in ISO/IEC 2382–1 and the following apply.
Other terms are defined where they appear in italic type.
3.1.1
language vulnerability
property (of a programming language) that can contribute to, or that is strongly correlated with, application
vulnerabilities in programs written in that language
Note 1: The term "property" can mean the presence or the absence of a specific feature, used singly or in
combination. As an example of the absence of a feature, encapsulation (control of where names can be
referenced from) is generally considered beneficial since it narrows the interface between modules and can
help prevent data corruption. The absence of encapsulation from a programming language can thus be
regarded as a vulnerability. Note that a property together with its complement can both be considered
language vulnerabilities. For example, automatic storage reclamation (garbage collection) can be a
© ISO/IEC 2010 – All rights reserved  1

ISO/IEC TR 24772:2010(E)
vulnerability since it can interfere with time predictability and result in a safety hazard. On the other hand,
the absence of automatic storage reclamation can also be a vulnerability since programmers can mistakenly
free storage prematurely, resulting in dangling references.
3.1.2
application vulnerability
security vulnerability or safety hazard, or defect
3.1.3
security vulnerability
weakness in an information system, system security procedures, internal controls, or implementation that could
be exploited or triggered by a threat
3.1.4
safety hazard
potential source of harm
Note 1: IEC 61508–4:  defines a “Hazard” as a “potential source of harm”, where “harm” is “physical injury or
damage to the health of people either directly or indirectly as a result of damage to property or to the
environment”.
Note 2: IEC 61508 is titled “Functional safety of electrical/electronic/ programmable electronic safety‐related
systems”, with part 4 being “Definitions and abbreviations”.  Hence within IEC 61508 the “safety” context of
“safety hazard” is assumed.
Note 3: IEC 61508 cites ISO/IEC Guide 51 as the source for the definition.
Note 4: Some derived standards, such as UK Defence Standard 00‐56, broaden the definition of “harm” to
include material and environmental damage (not just harm to people caused by property and environmental
damage).
3.1.5
safety‐critical software
software for applications where failure can cause very serious consequences such as human injury or death
Note 1: IEC 61508–4:  defines “Safety‐related software” as “software that is used to implement safety
functions in a safety‐related system.
Note 2: Notwithstanding that in some domains a distinction is made between safety‐related (can lead to any
harm) and safety‐critical (life threatening), this Technical Report uses the term safety‐critical for all
vulnerabilities that can result in safety hazards.
3.1.6
software quality
degree to which software implements the requirements described by its specification and the degree to which
the characteristics of a software product fulfil its requirements
2  © ISO/IEC 2010 – All rights reserved

ISO/IEC TR 24772:2010(E)
3.1.7
predictable execution
property of the program such that all possible executions have results that can be predicted from the source code
Note 1: All the relevant language‐defined implementation characteristics and knowledge of the universe of
execution must be known.
Note 2: In some environments, this would raise issues regarding numerical stability, exceptional processing,
and concurrent execution.
Note 3: Predictable execution is an ideal that must be approached keeping in mind the limits of human
capability, knowledge, availability of tools, and other factors. Neither this Technical Report nor any standard
ensures predictable execution. Rather this Technical Report provides advice on improving predictability. The
purpose of this Technical Report is to assist a reasonably competent programmer to approach the ideal of
predictable execution.
Note 4: The following terms are used in relation to “Predictable execution”.
 Unspecified behaviour: A situation where the implementation of a language will have to make some
choice from a finite set of alternatives, but that choice is not in general predictable by the programmer,
for example, the order in which sub‐expressions are evaluated in an expression in many languages.
 Implementation‐defined behaviour: A situation where the implementation of a language will have to
make some choice, and it is required that this choice be documented and available to the programmer.
 Undefined behaviour: A situation where the definition of a language can give no indication of what
behaviour to expect from a program – it can be some form of catastrophic failure (a ‘crash’) or continued
execution with some arbitrary data.
Note 5: This Technical Report includes a clause on Unspecified functionality. This notion is related to neither
unspecified behaviour, which is a characteristic of an application, nor the language used to develop the
application.
3.2   Symbols and conventions
3.2.1  Symbols
For the purposes of this document, the symbols given in ISO/IEC 80000–2 apply.  Other symbols are defined
where they appear in this document.
3.2.2   Conventions
Programming language token and syntactic token appear in courier font.
© ISO/IEC 2010 – All rights reserved  3

ISO/IEC TR 24772:2010(E)
4.  Basic Concepts
4.1  Not in Scope
This Technical Report does not address software engineering and management issues such as how to design and
implement programs, use configuration management tools, use managerial processes, and perform process
improvement.  Furthermore, the specification of properties to be assured is not treated.

The specification of an application is not within the scope.
While this Technical Report does not discuss specification or design issues, there is recognition that boundaries
among the various activities are not clear‐cut. This Technical Report seeks to avoid the debate about where low‐
level design ends and implementation begins by treating selected issues that some might consider design issues
rather than coding issues.
4.2  Approach
Guidelines based on this Technical Report are likely to be highly leveraged in that they are likely to affect many
times more people than the number that worked on them. Therefore guidelines such as these have the potential
to make large savings, for a small cost, or to generate large unnecessary costs, for little benefit.  For this reason,
the writers of this Technical Report have taken a cautious approach to identifying programming language
vulnerabilities.  New vulnerability descriptions can be added over time, as experience and evidence are
accumulated.
4.3  Intended Audience
The intended audience for this Technical Report is those who are concerned with assuring the existence of a
critical property in the software of their system; that is, those who are developing, qualifying, or maintaining a
software system and need to avoid language constructs that could cause the software to execute in a manner
other than intended.
As described in the following paragraphs, developers of applications that have clear safety, security or mission
criticality are expected to be aware of the risks associated with their code and could use this Technical Report to
ensure that their development practices address the issues presented by the chosen programming languages, for
example by subsetting or providing coding guidelines.
That should not be taken to mean that other developers can ignore this Technical Report. A weakness in an
application that of itself has no direct criticality may provide the route by which an attacker gains control of a
system or may otherwise disrupt co‐hosted applications that are safety, security or mission critical.
It is hoped that such developers would use this Technical Report to ensure that common vulnerabilities are
removed or at least minimized from all applications.
Several specific audiences for this International Technical Report have been identified and are described below.
4  © ISO/IEC 2010 – All rights reserved

ISO/IEC TR 24772:2010(E)
4.3.1  Safety‐Critical Applications
Users who may benefit from this Technical Report include those developing, qualifying, or maintaining a system
where it is critical to prevent behaviour that might lead to:
 loss of human life or human injury, or
 damage to the environment.
4.3.2  Security‐Critical Applications
Users who may benefit from this Technical Report include those developing, qualifying, or maintaining a system
where it is critical to exhibit security properties of:
 confidentiality,
 integrity, and
 availability.
4.3.3  Mission‐Critical Applications
Users who may benefit from this Technical Report include those developing, qualifying, or maintaining a system
where it is critical to prevent behaviour that might lead to:
 property loss or damage, or
 economic loss or damage.
4.3.4  Business‐Critical Systems
Users who may benefit from this Technical Report include those developing, qualifying, or maintaining a system
whose correctness and integrity are essential for successful operation of a business or enterprise.
4.3.5  Modeling and Simulation Applications
People who may benefit from this Technical Report include those who are primarily experts in areas other than
programming but need to use computation as part of their work. Such people include scientists, engineers,
economists, and statisticians. They require high confidence in the applications they write and use because of the
increasing complexity of the calculations made (and the consequent use of teams of programmers each
contributing expertise in a portion of the calculation), or to the costs of invalid results, or to the expense of
individual calculations implied by a very large number of processors used and/or very long execution times
needed to complete the calculations. These circumstances give a consequent need for high reliability and
motivate the need felt by these programmers for the guidance offered in this Technical Report.
4.4  How to Use This Document
This Technical Report gathers language‐independent descriptions of programming language vulnerabilities, as
well as selected application vulnerabilities, which have occurred in the past and are likely to occur again. Because
new vulnerabilities are always being discovered, it is anticipated that this Technical Report will be revised and
new descriptions added. For that reason, a scheme that is distinct from Technical Report sub‐clause numbering
© ISO/IEC 2010 – All rights reserved  5

ISO/IEC TR 24772:2010(E)
has been adopted to identify the vulnerability descriptions. Each description has been assigned an arbitrarily
generated, unique three‐letter code. These codes should be used in preference to sub‐clause numbers when
referencing descriptions.
The main part of this Technical Report contains descriptions that are intended to be language‐independent to the
greatest possible extent. Future editions will include annexes that apply the generic guidance to particular
programming languages.
This Technical Report has been written with several possible usages in mind:
 Programmers familiar with the vulnerabilities of a specific language can reference the guide for more
generic descriptions and their manifestations in less familiar languages.
 Tool vendors can use the three‐letter codes as a succinct way to “profile” the selection of vulnerabilities
considered by their tools.
 Individual organizations may wish to write their own coding standards intended to reduce the number of
vulnerabilities in their software products. The guide can assist in the selection of vulnerabilities to be
addressed in those standards and the selection of coding guidelines to be enforced.
 Organizations or individuals selecting a language for use in a project may want to consider the
vulnerabilities inherent in various candidate languages.
The following clauses include suggestions for ways of avoiding the vulnerabilities. It should be noted that these
include techniques that can be applied during development, and those that must be implemented as run‐time
checks. The former are likely to be appropriate to all applications. For some applications, it is relatively more
important to ensure that potential run‐time errors are eliminated during development because there may be
insufficient opportunity to recover from them.  For long‐running simulations, run‐time checks may increase the
run‐time to the point where the prediction loses value, or to the point where the cost of calculation becomes
prohibitive given the value of the simulation results.  Source code checking tools can be used to automatically
enforce some coding rules and standards.
Clause 2 provides Normative references, and Clause 3 provides Terms, definitions, symbols and conventions.
Clause 4 provides the basic concepts used for this Technical Report.
Issues, provides rationale for this Technical Report and explains how many of the
Clause 5, Vulnerability
vulnerabilities occur.
Clause 6, Programming Language Vulnerabilities, provides language‐independent descriptions of vulnerabilities in
programming languages that can lead to application vulnerabilities. Each description provides:
 a summary of the vulnerability,
 characteristics of languages where the vulnerability may be found,
 typical mechanisms of failure,
 techniques that programmers can use to avoid the vulnerability, and
 ways that language designers can modify language specifications in the future to help programmers
mitigate the vulnerability.
6  © ISO/IEC 2010 – All rights reserved

ISO/IEC TR 24772:2010(E)
Clause 7, Application Vulnerabilities, provides descriptions of selected application vulnerabilities which have been
found and exploited in a number of applications and which have well known mitigation techniques, and which
result from design decisions made by coders in the absence of suitable language library routines or other
mechanisms. For these vulnerabilities, each description provides:
 a summary of the vulnerability,
 typical mechanisms of failure, and
 techniques that programmers can use to avoid the vulnerability.
Annexes A through C are templates and guidelines that were used in the identification, selection, and creation of
the vulnerabilities that were generated for clauses 6 and 7. They can be used to guide the generation of future
language vulnerabilities and application vulnerabilities.
Annex D, Vulnerability Outline and List, is a categorization of the vulnerabilities of this report in the form of a
hierarchical outline and a list of the vulnerabilities arranged in alphabetic order by their three letter code.
Annex E, Language Specific Vulnerability Template, is a template for the writing of programming language specific
annexes that explain how the vulnerabilities from clause 6 are realized in that programming language (or show
how they are absent), and how they might be mitigated in language‐specific terms. Future revisions of this
Technical Report are planned to contain language‐specific annexes that are developed using Annex E.
© ISO/IEC 2010 – All rights reserved  7

ISO/IEC TR 24772:2010(E)
5  Vulnerability issues
Software vulnerabilities are unwanted characteristics of software that may allow software to behave in ways that
are unexpected by a reasonably sophisticated user of the software.  The expectations of a reasonably
sophisticated user of software may be set by the software's documentation or by experience with similar
into software by failing to understand the expected behaviour
software.  Programmers introduce vulnerabilities
(the software requirements), or by failing to correctly translate the expected behaviour into the actual behaviour
of the software.
This Technical Report does not discuss a programmer's understanding of software requirements or the
completeness of the requirements.  This Technical Report does not discuss software engineering issues per se.
This Technical Report does not discuss configuration management, build environments, code‐checking tools, nor
software testing.  This Technical Report does not discuss the classification of software vulnerabilities according to
safety or security concerns.  This Technical Report does not discuss the costs of software vulnerabilities, or the
costs of preventing them.
This Technical Report does discuss a reasonably competent programmer's failure to translate the understood
requirements into correctly functioning software.  This Technical Report does discuss programming language
features known to contribute to software vulnerabilities.  That is, this Technical Report discusses issues arising
from those features of programming languages found to increase the frequency of occurrence of software
vulnerabilities.  The intention is to provide guidance to those who wish to specify coding guidelines for their own
particular use.
A programmer writes source code in a programming language to translate the understood requirements into
working software. The programmer selects and codes constructs specified by a programming language with the
intention of achieving a written expression of the desired behaviour.
A program's expected behaviour might be stated in a complex technical document, which can result in a complex
sequence of features of the programming language.  Software vulnerabilities occur when a reasonably competent
programmer fails to understand the totality of the effects of the language features combined to construct the
software.  The overall software may be a very complex technical document itself (written in a programming
language whose definition is also a complex technical document).
The recommendations contained in this Technical Report might also be considered to be code quality issues. Both
kinds of issues might be addressed through the use of a systematic development process, use of
development/analysis tools and thorough testing.

5.1   Issues arising from incomplete or evolving language specifications
While there are many millions of programmers in the world, there are only several hundreds of authors engaged
in designing and specifying those programming languages defined by international standards.  The design and
specification of a programming language is very different from programming.  Programming involves selecting
and sequentially combining features from the programming language to (locally) implement specific steps of the
software's design.  In contrast, the design and specification of a programming language involves (global)
consideration of all aspects of the programming language.  This must include how all the features will interact
8  © ISO/IEC 2010 – All rights reserved

ISO/IEC TR 24772:2010(E)
with each other, and what effects each will have, separately and in any combination, under all foreseeable
circumstances.  Thus, language design has global elements that are not generally present in any local
programming task.
The creation of the abstractions which become programming language standards therefore involve consideration
of issues unneeded in many cases of actual programming.  Therefore perhaps these issues are not routinely
considered when programming in the resulting language.  These global issues may motivate the definition of
subtle distinctions or changes of state not apparent in the usual case wherein a particular language feature is
used.  Authors of programming languages may also desire to maintain compatibility with older versions of their
language while adding more modern features to their language and so add what appears to be an inconsistency
to the language.
For example, some languages may allow a subprogram to be invoked without specifying the correct signature of
the subprogram.  This may be allowed to keep compatibility with earlier versions of the language where such
usage was permitted, and despite the knowledge that modern practice demands the signature be specified.
Specifically, the programming language C does not require a function prototype be within scope .  The
programming language Fortran does not require an explicit interface.  Thus, language usage is improved by coding
standards specifying that the signature be present.
A reasonably competent programmer therefore may not consider the full meaning of every language feature
used, as only the desired (local or subset) meaning may correspond to the programmer's immediate intention.  In
consequence, a subset meaning of any feature may be prominent in the programmer's overall experience.
Further, the combination of features indicated by a complex programming goal can raise the combinations of
effects, making a complex aggregation within which some of the effects are not intended.
5.1.1  Compiler Selection
Compiler selection is important to ensure a system o
...