Programming Leftovers

posted by Roy Schestowitz on Oct 08, 2026

• Sean Goedecke ☛ How to read code

  The third reason — and I say this as a lover of literature and poetry — is that code is much more structurally complex than English texts. Even famously difficult books are syntactically simpler than most computer programs (for instance, grammatical dependencies are largely bounded by a single paragraph, while code dependencies can stretch across the entire codebase). Their primary difficulty lies in understanding the nuances of human nature being discussed, not in understanding what each word’s grammatical function is3. Large codebases are also just longer: War and Peace contains around 600,000 words, while most large modern codebases have that many lines.

• Farid Zakaria ☛ Nix wrote half of my debugger

  A classic simple example of a race condition is two threads depositing into one bank account. Each deposit reads the balance, writes a line to the ledger, then stores the balance plus the deposit. If one teller runs between the other’s read and store, it writes a stale balance over the other’s deposits. 💥

• East River Source Control ☛ When random is not actually random enough

  I fondly remember choosing this option several times when I was much younger, especially when writing C — its standard library does not offer anything beyond rand() — and also my other language de jour, Haskell. After all, it is a fairly immediate and intuitive solution when you have such a problem, and almost any codebase or language, no matter how austere or feeble, will have some mechanism to pick a random number.

  But there is a hidden problem with this solution: it doesn’t preserve the underlying uniform distribution of the given random_u64() function. That means that the variability of the chosen object you pick doesn’t respect what we might intuitively think: we might think every item has a 1/10 chance of being chosen. It does not.

• LWN ☛ Reducing undefined behavior in the C language [LWN.net]

  As a professor of biomedical engineering, Martin Uecker perhaps does not fit the profile of a typical presenter at Kernel Recipes. He is, however, a longtime Linux user, and works on free software for controlling magnetic resonance imaging (MRI) scanners. He was at the conference to talk about the C programming language, the specific problem of undefined behavior in C, and whether it can eventually be made into a memory-safe language.

  Why bother with C in 2026? It is, he said, still a great language. C is portable, stable over the long term, offers fast compilation, and the resulting binary code is fast. ""What you see is what you get""; it is easy to look at C code and have some idea of what the computer will actually do. There are a lot of tools for working with the language, and C gets out of the way when necessary.

  C does have a long history, and that affects the language as we see it today, he said. The C89 standard had to cope with a wide variety of hardware, including machines with signed-magnitude or one's-complement integer representations, segmented memory, exotic pointer representations, and surprising sizes for types. Some Honeywell machines, for example, had nine-bit bytes. That greatly complicated the task of writing a standard that would enable the writing of portable code.

• Rust

  • LWN ☛ Native support for Rust on the GPU [LWN.net]

    Christian Legnitto is the maintainer of rust-gpu and Rust CUDA, two libraries that make it possible to program a computer's graphics processing unit (GPU) from Rust. He isn't satisfied with the current state of GPU support in Rust, however. In a talk at RustConf 2026, he explained his vision for how the GPU could become an ordinary compiler target for normal Rust code, without the need for any special libraries or new ecosystem support. That vision is not yet fully implemented, but he does have a prototype that he is preparing to release.

  • LWN ☛ Listening to the radio with Rust [LWN.net]

    Many of the transmissions sent over the radio spectrum can be decoded with a relatively cheap hardware dongle. Thomas Eckert presented at RustConf 2026 in Montreal about his hobby: decoding radio transmissions with Rust. In his presentation, he covered all of the math necessary to get started with software-defined radio, and gave demonstrations of listening to AM and FM radio, as well as decoding transmissions from aircraft transponders. His slides and example code are available on GitHub.

    Eckert said that all of his demos relied on the same fundamental pipeline. He then ran a program that started picking up a FM radio station from Montreal's Mt. Royal. That signal starts as a current being applied to the transmitting antenna, pushing the electrons in the metal back and forth. A changing electric field means a changing magnetic field and vice versa; the changing field propagates out through the air until it reaches his antenna. For the FM and AM radio demos, that antenna was clipped to the side of the podium; for the aircraft demo, which uses a different wavelength, the antenna in question was located up on the roof, with the data relayed by a Raspberry Pi that the conference organizers had allowed him to place up there.