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

Linus Torvalds' good taste argument for linked lists, explained

github.com

Post reply on HN
Print view View original

291–300 of 339 posts

Re: Linus Torvalds' good taste argument for linked lists, explained

#291

Post by stuff4ben »

snarfy wrote: post #290
adrianN wrote: post #224

Earlier quoted context omitted.

And instead of adding a check and crashing visibly here you wait even longer until your program misbehaves due to the error? The longer the program runs after something went wrong, the harder it is to debug, and the more likely it becomes that you get an exploitable bug.

Performance is a feature and that null check has a cost. The code is correct. The null check is unnecessary. The bug is passing null in.

Safety is a feature and that null check prevents bugs. I'd rather have slow but safe code rather than fast but buggy code.

Re: Linus Torvalds' good taste argument for linked lists, explained

#292

Post by shallowthought »

axaxs wrote: post #213
shallowthought wrote: post #209

Earlier quoted context omitted.

That's a pretty big freakin thing to leave out, though. Code that depends on its context is, some would say, bad.

Simply put, safety slows code down. It's a matter of whether you know what's happening underneath or not. The more you try to make C completely safe, the more you slow it down and therefore remove the need to have written it in C in the first place. Whether that's a good thing or not is an exercise for the implementer.

That's irrelevant to what Linus is saying. He's not saying "this is good code, but only with the caveat that it's written in C and run in the Linux Kernel". He's saying that changing it to make it far more difficult to read and modify, but cleverer, has made it better code in general.

Re: Linus Torvalds' good taste argument for linked lists, explained

#293

Post by stuff4ben »

banachtarski wrote: post #269
larsrc wrote: post #229

Earlier quoted context omitted.

Are you arguing that we should leave known crash bugs in the code?

What you are espousing is known as “defensive programming” which is very much a bad thing (tm).

Clearly you've never worked with contract developers whose only purpose is to write a crap ton of code to get a "feature" out that crashes as soon as it encounters the real world. As they say, "doveryay, no proveryay" and it's served me well.

Re: Linus Torvalds' good taste argument for linked lists, explained

#294

Post by scythe »

adrianN wrote: post #224
yarcob wrote: post #216

Earlier quoted context omitted.

That code is not a general purpose library function; it assumes the element exists. If you call that method and the element doesn't exist, presumably something has gone wrong already. Adding a NULL pointer check is not going to fix it. You just silently ignore the error. You'll prevent the crash, but there's no mechanism for handling the error.

And instead of adding a check and crashing visibly here you wait even longer until your program misbehaves due to the error? The longer the program runs after something went wrong, the harder it is to debug, and the more likely it becomes that you get an exploitable bug.

Where you add safety checks like that is a top-down system organization issue, not something you can couch quarterback while looking at twelve lines from a million-line codebase. There is simply no way to determine if an assert is appropriate without further context, and it has nothing to do with the choice of algorithm.

Re: Linus Torvalds' good taste argument for linked lists, explained

#295

Post by doubletgl »

jraph wrote: post #70
galoisgirl wrote: post #34

Earlier quoted context omitted.

The same argument was made recently about the reduce function: it's a known pattern for some and a hard to understand trick for others.

Yes, and you get used to reduce. map, filter and reduce were hard for me to follow… until I used them two or three times and now I understand them easily and they naturally come to my mind when I need to solve a problem which they can help solving. They are good tools (especially in codebases shared with people who are allergic to loop statements!)

Agreed for map, filter etc. but reduce is the exception. There has been a fad of overusing it, until that article popped up which called it out.

Re: Linus Torvalds' good taste argument for linked lists, explained

#296

Post by pmart123 »

stuff4ben wrote: post #291
snarfy wrote: post #290

Earlier quoted context omitted.

Performance is a feature and that null check has a cost. The code is correct. The null check is unnecessary. The bug is passing null in.

Safety is a feature and that null check prevents bugs. I'd rather have slow but safe code rather than fast but buggy code.

Adding checks creates more code branches and tests. Passing null in is the bug.

Re: Linus Torvalds' good taste argument for linked lists, explained

#299

Post by sundarurfriend »

aksjfnkajsnd wrote: post #186
greenkey wrote: post #148

Earlier quoted context omitted.

I’m not a fan of everything Bukowski wrote, but I wouldn’t try to censor him so that little Jimmy could read it, and I liked the movie Barfly. Similarly, I’m not a fan of everything Linus wrote, but I wouldn’t enforce bad CS101 code on him so that little Jimmy could read it, and I like Linux.

Who is little Jimmy?

The poster-child for the movie "Think of the Children!"

Re: Linus Torvalds' good taste argument for linked lists, explained

#300

Post by nitrogen »

user-the-name wrote: post #256
nitrogen wrote: post #219

Earlier quoted context omitted.

I thought that only makes sense in JS. In C any nonzero value is considered "truthy", and on most architectures NULL is defined to be (void * )(0) or similar. The logical not operator AKA bang operator will replace truthiness with 0, and falsiness with 1. So applying it twice collapses all nonzero values to 1.

Well, yes, but that does absolutely nothing in this code, as it is immediately used as the argument to an if statement.

Indeed, I was only commenting on the JS vs C part.
Post reply on HN