Hi, I'm Tomasz

I was recently browsing the kernel code in attempts to understand some of the weird kernel errors I see in dmesg on one of my machines.

I was a bit surprised to see an interesting syntax I have never seen before. In the following code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

static int ucsi_run_command(struct ucsi *ucsi, u64 command, u32 *cci,
			    void *data, size_t size, bool conn_ack)
{
    ...
	/*
	 * Don't ACK connection change if there was an error.
	 */
	ret = ucsi_acknowledge(ucsi, err ? false : conn_ack);
	if (ret)
		return ret;

	return err ?: UCSI_CCI_LENGTH(*cci);
}

(Excerpt from ucsi usb code)

Being a bit bored and having a some extra time during Christmas motivated me to learn zig. As usual, when learning a new language, you experiment a bit, write some small test programs to discover the syntax and idiomatic ways to solve problems and learn the standard library. One of the fundamental things that you’ll eventually find the need for, sooner or later, is defining abstractions and interfaces, and I was a bit shocked to discover that zig simply doesn’t support that!

Here’s a quick summary of the tools I’ve picked up along the way in 2024 that I continuously find useful. I’ve divided the list into three sections, first one comprised mostly of general shell “helpers” that are part of my day to day workflow one way or another. The second one, focusing on my current nvim setup and the last one listing some tools deployed in my home lab or things I run on my servers that I find useful and worth mentioning as well.

I haven’t got a chance yet to play with asynchronous I/O APIs in any production application so, to fill in that gap I’ve decided to commit some time and experiment with posix AIO and liburing a try. These two are (I think?), at the time of writing, the two most popular APIs to perform asynchronous operations in Linux.

This post isn’t a benchmark nor a comparison between the two. It’s just a knowledge summary of the basics behind using these APIs and what I’ve learned along the way.

I’m currently in the process of writing a back-end for a small web application that I plan to deploy in my local environment. The application isn’t really relevant. The important bit is a new trick I learned while working on it.

Within the back-end, at some point, I’m parsing an user-agent string. These strings are standardised and should follow the format described by HTTP Semantics.

For convenience, I’ve chosen to go with uap-go to parse these strings and here lies the catch.

Lifetime problems

As a reminder, I want to start with a classic example of using an invalid this captured in a lambda acting as a delegate .

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#include <functional>
#include <iostream>
#include <memory>
#include <string>

class Item {
public:
    explicit Item(std::string name) :
        name{name}
    {}

    std::function<void()> makeHelloDelegate() {
        return [this]{ hello(); };
    }

    void hello() const {
        std::cout << "item: " << name << std::endl;
    }

private:
    std::string name;
};


int main() {
    auto item = std::make_unique<Item>("pencil");

    auto d = item->makeHelloDelegate();

    item.reset();

    // `this` captured in lambda is now invalid

    // undefined behaviour (SIGSEGV most likely)
    d();

    return 0;
}

This is a classic lifetime issue. The object is destroyed but its this pointer is still captured in lambda. An attempt to call the delegate d will be essentially, a use after free leading to undefined behaviour.

This is a short overview of things added along with c11 and c23 which I find useful or interesting.

auto keyword… yet again

auto has been repurposed in C23. Originally, it defined a storage duration for local variables (similarly as static) now, comparably as in C++, it can be used for type inference purposes.

1
2
3
4
5
6
7

void foo() {
    // auto is implied
    int i = 123;

    // same thing, auto keyword is redundant
    auto int j = 123;
}

In its original purpose, variables marked with auto have their storage automatically allocated and deallocated on scope entry and exit. It was implied for all local, stack variables. No one really used auto explicitly because it was just unnecessary now, it has an extra meaning.