The Role of Implicit Conversions in Erroneous Function Argument Swapping in C++

Argument selection defects, in which the programmer has chosen the wrong argument to a function call is a widely investigated problem. The compiler can detect such misuse of arguments based on the argument and parameter type in case of statically typed programming languages. When adjacent parameters have the same type, or they can be converted between one another, the potential error will not be diagnosed. Related research is usually confined to exact type equivalence, often ignoring potential implicit or explicit conversions. However, in current mainstream languages, like C++, built-in conversions between numerics and user-defined conversions may significantly increase the number of mistakes to go unnoticed. We investigated the situation for C and C++ languages where functions are defined with multiple adjacent parameters that allow arguments to pass in the wrong order. When implicit conversions are taken into account, the number of mistake-prone function declarations significantly increases compared to strict type equivalence. We analysed the outcome and categorised the offending parameter types. The empirical results should further encourage the language and library development community to emphasise the importance of strong typing and the restriction of implicit conversion.

I. Introduction

In statically typed programming languages, each parameter of a function is given a type, and the compiler is responsible for ensuring that only expressions of the expected type are given as argument. Unfortunately, the detection mechanisms in compilers are defeated if multiple parameters are declared adjacent to each other with the same type. A swap of adjacent arguments at a call site slips through semantic checks as the types of the swapped arguments still match the interface specified. Given a function fn (int x, int y), both fn (1, 2) and fn (2, 1) are valid calls. In addition, due to implicit conversions that are possible in various mainstream programming languages, such as C++, fn (1.5, 3) is also a valid call, even though the function is not directly taking floating-point values. Developers often use the identifier name of the parameter to convey semantic information about the values expected in place of a parameter. While research has been done on understanding natural language for multiple aspects of the software, including identifiers names [1]–[3], the semantic information conveyed by the identifiers themselves are not considered by virtually any compilers of mainstream languages.¹

Inline with the literature of the field, we will refer to formal parameters appearing in functions’ declarations and definitions as parameters, while the expressions from which actual parameters are calculated will be referred to as arguments.