CATEGORY: MITRE CWE-480: Use of Incorrect Operator REFERENCE: https://cwe.mitre.org/data/definitions/480.html EXPLANATION: Based on the requirement "... video files must be split up in chunks and no chunk may exceed 1 GB (10^9 bytes)", the developer created a symbolic constant: static const int maxChunkSize = 10^9; However, in C/C++, there is no exponentiation operator. While '^' is often used in writing to mean "raised to the power of", in C/C++ the '^' operator computes the 'exclusive OR' (XOR) of two operands. Consequently, 'maxChunkSize' is initialized to 3, not 1,000,000,000: Binary Decimal ----------------- 1010 10 XOR 1001 9 ----------------- 0011 3 CONSEQUENCES: While the code that processes uploads in chunks is correct, there will be 1000000000 / 3 times more chunk uploads than necessary. Since every chunk upload incurs overhead (e. g. a single TCP header is 20 bytes, almost 7 times more than the 3 byte payload), the whole upload process is very inefficient. BUGFIX: The easiest fix is to change the definition of 'maxChunkSize' like so: static const int maxChunkSize = 1000000000; The irony of this story is that the poor developer probably wanted to make the code easier to review and by doing so introduced the bug. A more readable, safer alternative is this: static const int maxChunkSize = 1000 * 1000 * 1000; Since C++14, there's an even better solution available, thanks to support for digit separators: static const int maxChunkSize = 1'000'000'000; REMARKS: I once witnessed a variant of this bug, involving a binary constant: static const size_t bufferSize = 2^20; // 1 MiB char buffer[bufferSize]; memcpy(buffer, data, datalength); When in fact this was intended: static const size_t bufferSize = 1 << 20; // 1 MiB Contrary to the video upload example, this programmer had more luck: the way-too-small buffer lead to many out-of-bounds accesses which often caused easy-to-debug core dumps. Sadly, bugs that "just" affect performance often have a much longer life-expectancy.