Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everybody makes mistakes when writing comparison functions

karpov2007.medium.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Everybody makes mistakes when writing comparison functions

#41

Post by junon »

jusssi wrote: post #34
junon wrote: post #24

Earlier quoted context omitted.

God I'm so tired of this take. "All code has bugs." "Everyone writes shitty code, some just make it less shitty." ad nauseum. I don't know where this started (more, when it got popular) but it's such a cop out and lazy argument to anything safety-related. It adds nothing to the discussion and provides no insight or substance, yet people parrot it often, especially around "language lawyer"-type HN articles. Moreover,…

You can formally prove that a function always does exactly what the author intended, no less, no more. But it still might be the wrong thing to do. The question is, do you count that as a bug or something else.

That's moving the goalposts, and not the point originally being made nor the point I'm addressing.

Re: Everybody makes mistakes when writing comparison functions

#42

Post by martincmartin »

The mistake I often see in interviews:

    int cmp(int a, int b) {
        return a - b;
    }
This can easily overflow or underflow. For example, if a = INT_MAX and b I don't count it against the person interviewing, because its common and arguably reasonable if your values are all < INT_MAX/2.

Re: Everybody makes mistakes when writing comparison functions

#43

Post by IncRnd »

petee wrote: post #16
ChrisMarshallNY wrote: post #12

I have a friend that used to be an OpenSSL contributor (not sure if he still is). Not really a big deal. There were a lot of them. He was generally cranky ["curmudgeonly"? -Ed.] about the code, and tried submitting quality fixes, where possible; but this was years ago. PVS-Studio looks great. I wish it worked on Swift. SwiftLint has its limitations.

I was surprised to read in the article that the code quality was good, unless they some how pulled off a major refactor since LibreSSL basically called the code a mess. If I recall, the claim was that OpenSSL prioritized issues paid for by companies, and the alot was left to rot. I'm curious if your friend saw the same things?

OpenSSL 3.0.0, which is what the article mentions, is a new version that is incompatible with older versions of OpenSSL. its internals operate in a completely different manner. It is a very changed codebase. That being said, I would not say its code quality is good, regardless of whether any tooling reports that.

Re: Everybody makes mistakes when writing comparison functions

#44

Post by gnulinux »

junon wrote: post #31
Levitz wrote: post #29

Earlier quoted context omitted.

I think every code has bugs in the same way that every gun is always loaded. Yes you can throughly check for it in some place and be rather sure that it's not loaded, but the way to act around it is as if it could always be loaded. This doesn't excuse writing buggy code, same as you should always handle a gun with care, but it promotes good behaviour around it.

This is nonsense. Comparing the two makes no sense. > Yes you can throughly check for it in some place and be rather sure Look up formal verification. You can prove, mathematically, that code is bug free.

I write code in Agda (a proof assistant) for a living and this is rarely true. Because (1) even if you prove your program is correct as per spec it doesn't prove it's correct according to user/PM since spec can/will be buggy (2) proving every single theorem about your system is an extraordinary time sink, an engineer needs to know what parts are higher risk and needs to be proven and which parts are corrolaries of basic algebra and proving is of academic interest.

EDIT: In my experience the biggest benefit you get from proof assistants like Coq, Agda etc is being able to run arbitrary unittests within your type system. It's convenient because it makes all bugs a type error and therefore possible to check at compile time. This doesn't mean agda will magically find all bugs, but it means you have more tools to do so.

Re: Everybody makes mistakes when writing comparison functions

#45

Post by HarHarVeryFunny »

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).

Re: Everybody makes mistakes when writing comparison functions

#46

Post by OneEyedRobot »

jeffbee wrote: post #37
OneEyedRobot wrote: post #33

On a related note, I think the most errors I've seen in sizable C++ systems has been operator overloading for things like '=' and '=='. Too much hidden magic can occur.

If you don't override or explicitly delete them you get compiler defaults, which are even more magic and harder for the reader to reason about.

I agree, and I think it's probably a good idea for any class that isn't a simple structure with functions.

I suppose that a problem with C++ (and the more feature-filled source control systems) is that it's dangerous to mix different levels of programmer sophistication in a team. The people are reflected in the code particularly as the obfuscation increases.

Re: Everybody makes mistakes when writing comparison functions

#47

Post by junon »

gnulinux wrote: post #44
junon wrote: post #31

Earlier quoted context omitted.

This is nonsense. Comparing the two makes no sense. > Yes you can throughly check for it in some place and be rather sure Look up formal verification. You can prove, mathematically, that code is bug free.

I write code in Agda (a proof assistant) for a living and this is rarely true. Because (1) even if you prove your program is correct as per spec it doesn't prove it's correct according to user/PM since spec can/will be buggy (2) proving every single theorem about your system is an extraordinary time sink, an engineer needs to know what parts are higher risk and needs to be proven and which parts are corrolaries of ba…

Bugs in spec != bugs in code. This is expressly moving the goalposts.

Re: Everybody makes mistakes when writing comparison functions

#48

Post by brabel »

As someone used to tools like IntelliJ for Java and Kotlin, and Clippy for Rust, this is like the most basic kind of warning I can imagine.

It blows my mind sometimes what IntelliJ, in particular, catches... like code branches that can never execute due to intricate conditional blocks in the same block of code... forgetting to use a method argument is not even worth a mention :D

Look at just how many issues IntelliJ can detect for Java: https://www.jetbrains.com/help/idea/list-of-java-inspections...

Re: Everybody makes mistakes when writing comparison functions

#49

Post by commandlinefan »

coldpie wrote: post #38
misnome wrote: post #10

Earlier quoted context omitted.

I also wonder this. "Unused parameter in function" is one of the most basic warning/linting checks. I'd be interested in finding out how this managed to reach release.

Having unused parameters is super common, especially when using function-pointer-based APIs like qsort. Arguably they should have annotated the arguments to suppress the warnings, but that starts to get into compiler compatibility (OpenSSL is used on a _lot_ of systems with a _lot_ of compilers) and becomes a much larger question than just setting -Wno-unused-parameter.

> especially when using function-pointer-based APIs like qsort

Well, the function should be called somewhere, even if it's ignored when null. I can't think of a legitimate case for an unused parameter - it might be #ifdef-ed out in some cases, but it should still be referenced somewhere.

Re: Everybody makes mistakes when writing comparison functions

#50

Post by commandlinefan »

junon wrote: post #24
kleiba wrote: post #8

Everybody makes mistakes writing any kind of function.

God I'm so tired of this take. "All code has bugs." "Everyone writes shitty code, some just make it less shitty." ad nauseum. I don't know where this started (more, when it got popular) but it's such a cop out and lazy argument to anything safety-related. It adds nothing to the discussion and provides no insight or substance, yet people parrot it often, especially around "language lawyer"-type HN articles. Moreover,…

> Not every function has a bug

Ok, you're right. Every non-trivial function has a bug.

Post reply on HN