5 ms·
I believe the implicit requirement is that the item is known to exist within the list. With that requirement in place the extra guards aren't requisite (they'r
by mjevans 6y ago
I believe the implicit requirement is that the item is known to exist within the list. With that requirement in place the extra guards aren't requisite (they're implicit) and in kernel code this probably offers a performance edge and is a reasonable requirement. Either having an implementation that has an extra check once at the end of the list, or that verifies the presence of the item and passes that node through to a deletion subroutine, would be good alternatives but still utilize the same pointer to structure view.
- shallowthought 6y agoThat's a pretty big freakin thing to leave out, though. Code that depends on its context is, some would say, bad.
- cmroanirgo 6y agoThis is why Linus' code shouldn't be copied verbatim and used in the real world. The Kernel is an extremely isolated and contained system. At the very least, the code should add comments on the the assumptions that are vital...otherwise n00bs will copy the code as gospel and run into all sorts of problems.
- ggrrhh_ta 6y agoThe actual code in the kernel is well documented (and different, lines 103-149): https://github.com/torvalds/linux/blob/master/include/linux/list.h https://github.com/torvalds/linux/blob/master/include/linux/...
- axaxs 6y agoSimply 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.
- inglor_cz 6y agoTrue, but costs of comparison to NULL aren't massive. It is one of the fastest things out there. It was my experience when tuning a linear algebra library (just for internal use) that such comparisons are almost unobservable in total performance tests.
- atq2119 6y agoIf you're writing a linear algebra library, then the bulk of executing code should be floating point vector operations in tight loops with known bounds. A NULL pointer check in the prolog where you set up the loop is going to be negligible. This is very different from kernel code, which by its nature isn't very computational but doing resource management all day long and pretty much all it does is stuff that looks like walking linked lists.
- inglor_cz 6y agoThat was a very specific linear algebra, we toyed around with huge but sparse matrices. Not anything graphics-related, rather number theory-related. But there was a lot of integer comparisons in there. This was around 2001-2002 anyway. Things might have changed.
- scoutt 6y ago> costs of comparison to NULL aren't massive Depends on how often you are doing the comparison. Is it 1 time/second, or 10 million times a second? There is a difference. If the code above is the one in charge of putting/removing network packets in a queue, or putting threads ordered by priority for the scheduler, then you should consider the side effects of checking for NULL. If you are going to implement this function in a library for Jimmy The Programmer[1], then check for NULL. [1] https://blog.codinghorror.com/new-programming-jargon/ https://blog.codinghorror.com/new-programming-jargon/
- GoblinSlayer 6y agoIt's written in C because C is popular, has platform support and the code was originally written in C, not because the kernel should be a security nightmare.