Live data from Hacker News

Everybody makes mistakes when writing comparison functions

karpov2007.medium.com

31–40 of 63 posts

Re: Everybody makes mistakes when writing comparison functions

#31
post #29
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,…

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.

Re: Everybody makes mistakes when writing comparison functions

#34
post #24
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,…

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.

Re: Everybody makes mistakes when writing comparison functions

#35
post #28
post #21

Earlier quoted context omitted.

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.

it's very ver hard to get an in-production project True, especially for older projects which never cared about warnings to begin with. Still when I encounter one I might try it anyway, gradually if possible, to see what comes out. Not just because it is indeed just joy to have no warnings, but also because more often than not some of those warnings actually tell you there are bugs. Or for example (just had this last…

Absolutely.

One strategy I employed with a very old code base with a gajillion warnings was to output them to a file and compare against a reference file at the end of the build. If the output changed we would fix those and maybe any that kept happening if you added new compilation units etc. It at least helped us slowly reverse the trend of accumulating warnings.

Re: Everybody makes mistakes when writing comparison functions

#36
post #15
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.

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

Reading https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html, which says

“In order to get a warning about an unused function parameter, you must either specify -Wextra -Wunused (note that -Wall implies -Wunused), or separately specify -Wunused-parameter.”

So, it seems one can do

  -Wunused-parameter

Re: Everybody makes mistakes when writing comparison functions

#37

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.

Re: Everybody makes mistakes when writing comparison functions

#38
post #10
post #3

Unused function argument is a warning any sane compiler can spit out and turn into a hard error (so this is not really the best example of what PVS studio can do for you), which makes one wonder: why was this not caught earlier? Warnings not enabled, or ignored, and is that something which is problematic wrt something as major as OpenSSL?

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.

Re: Everybody makes mistakes when writing comparison functions

#39
post #31
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.

No, that does not follow, it is actually a common logical flaw.

What you can prove with formal verification is that the code conforms to the sacro-saint spec. But who says the spec is bug-free?

Re: Everybody makes mistakes when writing comparison functions

#40
post #15

Earlier quoted context omitted.

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

You've got to love that -Wall rusted in place as meaning not, in fact, all warnings, but instead just some arbitrary set of warnings that some people wanted many years ago and now we mustn't change it because too many projects have code that builds under -Wall -Werror only because the warnings that code triggers weren't covered by -Wall many years ago. https://xkcd.com/1172/ in action

GHC has the correct policy, that -Werror is not recommended, and if you use it there are no guarantees your build won't break on the future.

Every compiler should adopt it. And every build tool should stop printing thousands of lines of "build tool passed here" on the default verbosity.

Post reply on HN