The transaction cost in terms of gas can vary based on current network conditions, for example, the gas cost of EVM (Ethereum Virtual Machine) instructions during a hard fork might significantly be affected. This can break existing functionality that relies on fixed amounts of gas or can affect transactions utilized for value transfer such as transfer() and send(), which use a fixed amount of 2300 gas.

Example 1: The following code carries out a call and specifies a fixed amount of gas.

interface ICallable {
    function callMe() external;
}

contract HardcodedNotGood {
    function callWithArgs() public {
        callable.callMe{gas: 10000}();
    }
}

When developing a Solidity smart contract, developers must set the visibility of state variables to control who can get or set them.

Explicitly setting the visibility on state variables makes it easier to catch incorrect assumptions about who can access the variable.

Example 1: The following code fails to set an explicit level of visibility to a variable.

bytes16 data = "data";

When using Solidity compiler versions prior to version 0.5.0, developers can define a constructor by creating a function with the same name as the containing contract. Constructors in general are reserved for sensitive functionality and meant to be run only at contract creation. If the constructor has a typo such that the name does not match the contract name, then the sensitive functionality in the constructor is exposed.

Example 1: The following code uses a Solidity compiler version earlier than 0.5.0 and tries to declare a constructor with a name that does not exactly match the contract name. In this example, the case of the contract name and the constructor name do not match (Missing vs missing).

pragma solidity 0.4.20;

contract Missing {
    address private owner;
    function missing() public {
        owner = msg.sender;
    }
}

When creating a Solidity smart contract developers can specify the compiler version to use in order to clarify what version it has been tested against and prevent any problems from using a different version of the compiler. However, many compiler-related vulnerabilities have been publicly disclosed over the years and newer patched versions of the compiler have been created to address those issues.

Developers can specify a range of compatible Solidity compiler versions to use when creating a smart contract. This is not recommended because the contract is usually developed and tested in only one of the possible versions. This leaves open the possibility of compiling it using an outdated version of the compiler that has known security vulnerabilities.

Example 1: The following line of code sets the pragma so that the smart contract will not compile in versions earlier than 0.4.5 and it will also not work on compilers of version 0.5.0 and later.

pragma solidity ^0.4.5;

When an unsigned character cast to an integer is assign to a signed character, its value might be indistinguishable from EOF.

Example 1: The following code reads a character and compares it to EOF.

char c;

while ( (c = getchar()) != '\n' && c != EOF ) {
  ...
}

In this case, the return value from getchar() is cast to a char and compared to EOF (an int). Assuming c is a signed 8-bit value and EOF is a 32-bit signed value, then if getchar() returns a character represented by 0xFF, the value of c will be sign extended to 0xFFFFFFFF in the comparison to EOF. Since EOF is typically defined as -1 (0xFFFFFFFF), the loop will terminate erroneously.

It is dangerous to rely on implicit casts between signed and unsigned numbers because the result can take on an unexpected value and violate weak assumptions made elsewhere in the program.

Example 1: In this example the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned int, amount will be implicitly converted to unsigned.

unsigned int readdata () {
	int amount = 0;
    ...
	if (result == ERROR)
		amount = -1;
	...
	return amount;
}

If the error condition in Example 1 is met, then the return value of readdata() will be 4,294,967,295 on a system which uses 32-bit integers.

Conversion between signed and unsigned values can lead to a variety of errors, but from a security standpoint is most commonly associated with integer overflow and buffer overflow vulnerabilities.