Toward a better list iterator for the Linux kernel

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • ccan

    The C Code Archive Network

    For more advanced intrusive lists in C, I've found that ccan's tlist2 (https://github.com/rustyrussell/ccan/blob/master/ccan/tlist2...) provides a decent model here.

    Compared to the linux kernel's intrusive lists, it also tracks the offset of the list_node within the structure contained by the list, which eliminates another class of problems. It does still have the "using the iterator after the for loop is over" issue discussed in this article, but it also already tracks the types as Linus proposed doing in the article to resolve the issue.

  • freebsd-src

    The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests....

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • zig

    General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

    I don't use Zig but follow its development a bit. Zig has or may add foreach-like loops over one or more collections: https://github.com/ziglang/zig/issues/7257#issuecomment-1030...

  • rust

    Empowering everyone to build reliable and efficient software.

    > 40 years of history being deployed

    How do you figure? The C++ Core Guidelines date back to at least 2017, so 40 years before that would be 1977. At which point Stroustrup is still in Cambridge as a PhD student under Wheeler, he doesn't even travel to Bell Labs until after completing his Thesis.

    Let's be honest here, the C++ Core Guidelines aren't because C++ is 20 or 30 or (if you squint very hard) 40 years old, they are a symptom of two things: 1. C++ programmers, including those on the Committee itself, don't agree about which dialect of C++ is good to use; 2: The ISO process is not well-suited to this work, even abused heavily it is a poor fit to the actual problem of standardizing a programming language under active development.

    Rust avoids both these problems by choosing a more appropriate mechanism for decision making, one much more like that used at the IETF. The goal is to achieve consensus rather than getting one extra vote to put your favoured outcome over the line. The main casualties of a consensus approach are that "Marmite" proposals don't get far, however even if they survive the ballot process in a democracy they're likely to meet a terrible fate in the real world for the same reason - too many people hate them. On the other hand, mediocre proposals tend to get considerably improved during consensus making because there isn't any points scoring.

    For example look at https://github.com/rust-lang/rust/pull/93208 -- The proposer initially wanted to offer Add for Wrapping but is it really clear this always does what the programmer expected? And if we're offering Add for Wrapping for symmetry we should also do Add> for T right? So in the end the consensus is let's just offer AddAssign because it's very clear in that case what's going on and it isn't symmetrical. And that's what will land in 1.60 next month.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts