4 ms·

Not being used to C syntax, I took this as a typo at first: indirect = &(*indirect)->next; The position of the parentheses make it look like you're derefe

Not being used to C syntax, I took this as a typo at first: indirect = &(*indirect)->next; The position of the parentheses make it look like you're dereferencing only (* indirect). But on second look, you need the parens there so that it's (* indirect)->next as opposed to indirect->next. Then the & operates on the whole thing. I'd be tempted to wrap it in a second set of parens for clarity, but perhaps it's entirely obvious to a programmer who's actually used to using pointers. IE: indirect = &((*indirect)->next);

TickleSteve 10y ago
To me, its 'clever' code.... i.e. it should be simplified. This is not good code, it requires too much thought to realise what its doing.
- tempestn 10y ago
  It's busier to look at due to the syntax of the language, but if you're comfortable with pointers one could argue that it's conceptually simpler than the first example. And since linked lists are all about pointers, operating on the pointer directly seems logical. That said, for someone unused to the syntax (as I am!), I agree that it is definitely harder to mentally parse. So which is objectively better probably depends on your audience.
  - palunon 10y ago
    >So which is objectively better probably depends on your audience. I guess when your audience is kernel developers, this isn't that much of a problem...
    - TickleSteve 10y ago
      not true at all.... kernel developers are not mythical beasts, they're just regular low-level developers. Nothing special. I've got 20 years experience developing this kind of stuff and to me, its not as simple as it could be, therefore it could be better.
      - palunon 10y ago
        Maybe. But if it is a common idiom in the linux kernel (is it ?), it doesn't mean anything that the first time you encounter it you will take some small amount of time understanding it, because then you'll know about it, and it won't cause any problem in the future.
      - RandomOpinion 10y ago
        You have 20 years of experience on this kind of stuff and don't recognize the textbook example code for handling the head pointer case of a linked list? Well, okay... (It's at least 23 years old because I learned from textbooks that have this example code way back then. It probably dates all the way back to K&R.)
        TickleSteve 10y ago
        What textbook would that be exactly?? (not that it matters) The point isn't "can I understand it"... the point is "Would someone who hadn't seen it before have to do another mental operation to understand it?" ...and yes... dereferencing is another operation you have to do in your head to understand it.
        RandomOpinion 10y ago
        Well, I'm at work so I can't dig around my library but it was easy enough using date range restrictions to find an academic example in Google that dates back to '99: http://cslibrary.stanford.edu/105/LinkedListProblems.pdf http://cslibrary.stanford.edu/105/LinkedListProblems.pdf . (It was actually the first hit.) Searching further backwards in time is left as an exercise to the reader. Multi-level pointer dereferencing is a fundamental C / assembly language skill and Linus' example was just about the most basic example there is.
        TickleSteve 10y ago
        We will have to agree to disagree on that point.... And I have just as much experience in c as Linus.
- GarvielLoken 10y ago
  Worse is better
thomasahle 10y ago
I think the whole example comes down to Linus being really good at C. He wants code from people who are similarly fluent in the idioms and syntax of the language.
smitherfield 10y ago
It's quite clear to me[0]: The member access and subscript operators (. -> []) have the highest precedence, and the pointer dereference and address-of operators (* &) bind from right to left. And in any event if you left out the parentheses the compiler or IDE would likely catch your error. [0] As someone who likes coding in C/C++ for fun but has never for my day job.
marcosdumay 10y ago
Personally, I've never been able to memorize the precedence ordering of *, &, ., and ->, so I always use those extra parenthesis on non-trivial lines. But if it goes naturally for somebody, more power for them. It'll just take me a few more seconds reading a few lines.

TickleSteve 10y ago

To me, its 'clever' code.... i.e. it should be simplified. This is not good code, it requires too much thought to realise what its doing.

tempestn 10y ago
It's busier to look at due to the syntax of the language, but if you're comfortable with pointers one could argue that it's conceptually simpler than the first example. And since linked lists are all about pointers, operating on the pointer directly seems logical. That said, for someone unused to the syntax (as I am!), I agree that it is definitely harder to mentally parse. So which is objectively better probably depends on your audience.
- palunon 10y ago
  >So which is objectively better probably depends on your audience. I guess when your audience is kernel developers, this isn't that much of a problem...
  - TickleSteve 10y ago
    not true at all.... kernel developers are not mythical beasts, they're just regular low-level developers. Nothing special. I've got 20 years experience developing this kind of stuff and to me, its not as simple as it could be, therefore it could be better.
    - palunon 10y ago
      Maybe. But if it is a common idiom in the linux kernel (is it ?), it doesn't mean anything that the first time you encounter it you will take some small amount of time understanding it, because then you'll know about it, and it won't cause any problem in the future.
    - RandomOpinion 10y ago
      You have 20 years of experience on this kind of stuff and don't recognize the textbook example code for handling the head pointer case of a linked list? Well, okay... (It's at least 23 years old because I learned from textbooks that have this example code way back then. It probably dates all the way back to K&R.)
      - TickleSteve 10y ago
        What textbook would that be exactly?? (not that it matters) The point isn't "can I understand it"... the point is "Would someone who hadn't seen it before have to do another mental operation to understand it?" ...and yes... dereferencing is another operation you have to do in your head to understand it.
        RandomOpinion 10y ago
        Well, I'm at work so I can't dig around my library but it was easy enough using date range restrictions to find an academic example in Google that dates back to '99: http://cslibrary.stanford.edu/105/LinkedListProblems.pdf http://cslibrary.stanford.edu/105/LinkedListProblems.pdf . (It was actually the first hit.) Searching further backwards in time is left as an exercise to the reader. Multi-level pointer dereferencing is a fundamental C / assembly language skill and Linus' example was just about the most basic example there is.
        TickleSteve 10y ago
        We will have to agree to disagree on that point.... And I have just as much experience in c as Linus.
GarvielLoken 10y ago
Worse is better

thomasahle 10y ago

I think the whole example comes down to Linus being really good at C. He wants code from people who are similarly fluent in the idioms and syntax of the language.

smitherfield 10y ago

It's quite clear to me[0]: The member access and subscript operators (. -> []) have the highest precedence, and the pointer dereference and address-of operators (* &) bind from right to left. And in any event if you left out the parentheses the compiler or IDE would likely catch your error. [0] As someone who likes coding in C/C++ for fun but has never for my day job.

marcosdumay 10y ago

Personally, I've never been able to memorize the precedence ordering of *, &, ., and ->, so I always use those extra parenthesis on non-trivial lines. But if it goes naturally for somebody, more power for them. It'll just take me a few more seconds reading a few lines.