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

21–30 of 63 posts

Re: Everybody makes mistakes when writing comparison functions

#21

Post by jahnu »

pabs3 wrote: post #15
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.

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.

Re: Everybody makes mistakes when writing comparison functions

#22

Post by tialaramex »

pabs3 wrote: post #15
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.

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

Re: Everybody makes mistakes when writing comparison functions

#23

Post by IanSanders »

jahnu wrote: post #21
pabs3 wrote: 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.

Warning definitions also change over time with new versions

Re: Everybody makes mistakes when writing comparison functions

#24

Post by junon »

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, it's wrong. Not every function has a bug. Yes, there are ways to prove this. No, not every function needs to protect against the computer being struck by lightning, or any other fault, in every case. It's such a weird and wrong argument and it's always said with such confidence.

Re: Everybody makes mistakes when writing comparison functions

#26

Post by sethammons »

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,…

The idea that all software is terrible or all code has bugs is leveraged at my work as a form of psychological safety. "Yes, 'all' software has bugs, so you should feel safe exposing a bug you made and we can all learn from it." A person who took the saying as an excuse to be sloppy would get called out hard on our teams and wouldn't last if they kept that view.

Re: Everybody makes mistakes when writing comparison functions

#27

Post by vlovich123 »

NohatCoder wrote: post #17
jraph wrote: post #6

Earlier quoted context omitted.

> Why is a separate static analyzer necessary for this Because this is a nail this co-founder of PVS-Studio saw while holding the hammer he wants to sell. By the way, it seems to me this error does not have much to do with comparison functions, it is a mistake that can be made in many kinds of functions. Unused parameters are warned against in C (hence all the UNUSED macro hacks) and no static analyzers are going to…

Last time OpenSSL was in the news for a bug that should generate a warning I took a cursory look at some of the code, it was stuffed with stuff that would generate similar warnings. So at that time I concluded that going through all the warnings would be a pretty big job, and that is likely why nobody did so. On the more speculative front, it might be that some maintainer is against taking whitespace patches, that wo…

“The code quality is excellent” is either the author hedging pissing people off who are fans of OpenSSL or their analyzer doesn’t spot a lot of issues and thus they conclude it’s excellent for those reasons.

Re: Everybody makes mistakes when writing comparison functions

#28

Post by stinos »

jahnu wrote: post #21
pabs3 wrote: 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.

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 week) because there are projects which compile with 10k+ warnings which mean that even if you just compile a single file, it is way to hard to tell whether your new code just introduced a new warning and if so which one it is.

Re: Everybody makes mistakes when writing comparison functions

#29

Post by Levitz »

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,…

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.

Re: Everybody makes mistakes when writing comparison functions

#30

Post by adrian_b »

vlovich123 wrote: post #27
NohatCoder wrote: post #17

Earlier quoted context omitted.

Last time OpenSSL was in the news for a bug that should generate a warning I took a cursory look at some of the code, it was stuffed with stuff that would generate similar warnings. So at that time I concluded that going through all the warnings would be a pretty big job, and that is likely why nobody did so. On the more speculative front, it might be that some maintainer is against taking whitespace patches, that wo…

“The code quality is excellent” is either the author hedging pissing people off who are fans of OpenSSL or their analyzer doesn’t spot a lot of issues and thus they conclude it’s excellent for those reasons.

Actually the author said that the “The code quality is excellent” specifically about the new version 3.0 in contrast with the older OpenSSL versions, where he could find much more problems.

I have not looked yet at the new version, which has a very large number of changes, but it is quite possible that the author is right and that the rewritten code is very good.

Post reply on HN