0
I saw this tweet go by. No, I don't think it's good code:
What this code is trying to solve is the "integer overflow" vulnerability. I don't think it solves the problem well.
The first problem is that the result is
undefined. Some programmers will call
safemulti_size_t() without checking the result. When they do, the code will behave differently depending on the previous value of
*res. Instead, the code should return a defined value in this case, such as
zero or
SIZE_MAX. Knowing that this sort of thing will usually be used for memory allocations, which you want to have fail, then a good choice would be
SIZE_MAX.
The worse problem is
integer division. On today's Intel processors, integer multiplication takes a single clock cycle, but integer division takes between 40 and 100 clock cycles. Since you'll be usually dividing by small numbers, it's likely to be closer to 40 clock cycles rather than 100, but that's still really bad. If your solution to security problems is by imposing unacceptable tradeoffs, then you are doing security wrong. If you introduced this level of performance
Continue reading