Live data from Hacker News

Everybody makes mistakes when writing comparison functions

karpov2007.medium.com

61–63 of 63 posts

Re: Everybody makes mistakes when writing comparison functions

#61

I don't see how that's specific to comparison functions. It's just a result of someone not unit-testing their code. I was expecting to see an example of structure comparisons such as struct date {int year; int month; int day;} which are easy to get wrong unless you've internalized the pattern (or use modern C++ where it'll generate the comparison operators automatically for you).

The main specific is that it’s one of the most common errors. People don’t check comparison functions, but those functions have errors. You can read more here: https://pvs-studio.com/en/blog/posts/cpp/0509/

Re: Everybody makes mistakes when writing comparison functions

#62
post #21
post #15

Earlier quoted context omitted.

Both GCC and clang warn about unused parameters, but only when you run them with -Wextra.

As lots of us know from experience, it's very ver hard to get an in-production project into a warning free state with warnings at maximum and warnings as errors. I'm currently working on a new project this year and it has been such a joy to have near max compiler warnings as errors with multiple compilers (and clang tidy and clang format) right from the start.

Integration of a static analyzer into an existing project may be hard. Especially if the project is big and old. In fact, it’s not as scary as it seems to be. There are ways to do it as easy as possible: How to introduce a static code analyzer in a legacy project and not to discourage the team - https://pvs-studio.com/en/blog/posts/0743/

Re: Everybody makes mistakes when writing comparison functions

#63
post #54

I was a bit disappointed when the focus is not related to cryptography. I.e. a poorly written comparison function compares multiple expressions and the use of && short-circuit the logic, result in a timing attack. Would love to read an article about this topic, i.e. how to write a function whose execution time is constant regardless of the inputs, and thus not leak any side-channel information to the attacker.

I agree, it’s a bit of one-sided point of view. It’s only about the code quality. The cryptography analysis is beyond static analysis tools’ capabilities. Static analysis is more high-level study.
Post reply on HN