Linus Torvalds' good taste argument for linked lists, explained • Hacker News Board

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

#281

Post by slashdev » Mon, Dec 07, 2020, 2:14 PM UTC

coldtea wrote: post #90

ewindal wrote: post #85

Earlier quoted context omitted.

Conditionals are so simple it’s basically the first thing anyone learns. Anyone can understand the first approach. The latter requires knowledge that is specific to lower level languages,concepts that are certainly not taught universally. The latter approach is definitely not the easiest to understand. It is, however, what Linus considers «good taste in coding.»

> Conditionals are so simple it’s basically the first thing anyone learns. That's neither here, nor there though. The simplicity of a concept does not directly translate to how hard it makes the code (assembly is simpler in the sense of having fewer and simpler constructs than e.g. Python but much much harder to code in). Conditionals, and the exponential increase in state space they bring, are still one of the bigge…

Yes, excellently put. That's exactly why Linus' code is easier to understand. The extra control flow operations really increases the time to understand if the code is correct and likewise introduces many opportunities for error.

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

#282

Post by [deleted] » Mon, Dec 07, 2020, 2:15 PM UTC

majewsky wrote: post #253

rocqua wrote: post #248

Earlier quoted context omitted.

Hacker news has code blocks. Have the block indented by for spaces. this line has 4 spaces in front of it. What Hacker news could use instead are quote blocks. Now people often use the code blocks as quote blocks.

HN codeblocks are just two spaces indented. Any extra spaces indent further. This has no superfluous indentations.

[deleted]

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

#283

Post by adrianN » Mon, Dec 07, 2020, 2:17 PM UTC

zabzonk wrote: post #279

adrianN wrote: post #267

Earlier quoted context omitted.

Imo every piece of code (for reasonable definitions of "piece") is supposed to check its own preconditions and not rely on the caller to check them.

This isn't possible in many cases - consider the simple C library function strlen, one of who's preconditions is that it must only be called on a zero-terminated string. There is no way to write code in strlen to check that this is true.

Which is one of the reasons why coding standards like MISRA forbid using strlen (at least in C++, I guess even MISRA doesn't want to force you to write safer C with sane string types).

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

#284

Post by adrianN » Mon, Dec 07, 2020, 2:20 PM UTC

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

I'm interested in hearing more about why defensive programming is bad. Do you have some links for me?

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

#285

Post by augustk » Mon, Dec 07, 2020, 2:23 PM UTC

DonHopkins wrote: post #278

Back in the 80's, I learned Pascal, and learned about its dynamically allocated records, then I went on to learn C, and got used to its pointers and arrays. Then I went back to Pascal, and designed a program in my head with some dynamically allocated linked list data structures, and another data structure that had a member that pointed to the head of the linked list. Then I started typing in the Pascal code, and hit…

Most programming languages don't have an "address of" operator. That's because it's a potentially unsafe operation. I think your usage of Pascal sounds more like trying to operate a motorcycle like a bicycle.

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

#286

Post by HunterWare » Mon, Dec 07, 2020, 2:25 PM UTC

adrianN wrote: post #274

veets wrote: post #271

Earlier quoted context omitted.

This is nice in theory but a bad idea in practice (as a blanket statement, I am all for checking preconditions in general). An easy example is binary search, which I think is a reasonable "piece" of code by your definition. One should never check its preconditions _inside_ the binary search function (that the list of elements being searched is partitioned by the search predicate). Checking the precondition is O(n) wh…

You're right, but checking for null is not terribly expensive compared to iterating over a linked list.

The thing is that you aren’t really advocating for just that... Since this is pretty general support library code, the result of this philosophy is defensive checks in all support functions and that means checks every spinlock, mutex/semaphore, and god knows how many other places... everything really. We also would want these checks at multiple levels since we shouldn’t trust that other people checked things. This would have a significant effect on performance and many would prefer their system not to run however-many percent slower. All to avoid a possible issue that can’t be very large or systems would be kernel panic’ing all over the place.

From a black box, zero-knowledge, perspective it’s maybe worth remembering that code built this way successfully runs mission critical systems all over the world every day. Thoughtful people would have switched to other (slower, more pedantic) systems if doing things differently was a real overall life improvement. People have had the choice, there are plenty of OS’s out there... some far more formal/pedantic. Linux wasn’t the safe choice back in the day, it was just better by several important metrics consistently over time.

Perhaps these insanely experienced kernel devs know what they are doing.

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

#287

Post by andrepd » Mon, Dec 07, 2020, 2:29 PM UTC

adrianN wrote: post #235

larsrc wrote: post #229

Earlier quoted context omitted.

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

I'm arguing that we should use asserts or similar defensive coding mechanisms to ensure that preconditions are met instead of merrily continuing to run our program with cascading error effects.

Asserts have run-time cost. What you need is to ensure ensure those preconditions are met in the first place, statically, by formal methods for example.

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

#288

Post by vorhemus » Mon, Dec 07, 2020, 2:56 PM UTC

Good code is code that everyone in a team can understand, safely modify and maintain.

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

#289

Post by DonHopkins » Mon, Dec 07, 2020, 2:57 PM UTC

augustk wrote: post #285

DonHopkins wrote: post #278

Back in the 80's, I learned Pascal, and learned about its dynamically allocated records, then I went on to learn C, and got used to its pointers and arrays. Then I went back to Pascal, and designed a program in my head with some dynamically allocated linked list data structures, and another data structure that had a member that pointed to the head of the linked list. Then I started typing in the Pascal code, and hit…

Most programming languages don't have an "address of" operator. That's because it's a potentially unsafe operation. I think your usage of Pascal sounds more like trying to operate a motorcycle like a bicycle.

Pascal has what it call pointers, but doesn't have what C calls pointer arithmetic, or a way to take the address of any field of a structure or any element of an array.

So Linus's elegant linked list solution is possible in C, but not Pascal.

I don't get your metaphor that Pascal is a motorcycle and C is a bicycle. Just the opposite.

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

#290

Post by snarfy » Mon, Dec 07, 2020, 3:53 PM UTC

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.

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.