Another day, another Advent of Code 2020 problem.

That one seems fun! For some nerdy values of fun.

Our input is a set of rules:

light red bags contain 1 bright white bag, 2 muted yellow bags. dark orange bags contain 3 bright white bags, 4 muted yellow bags. bright white bags contain 1 shiny gold bag. muted yellow bags contain 2 shiny gold bags, 9 faded blue bags. shiny gold bags contain 1 dark olive bag, 2 vibrant plum bags. dark olive bags contain 3 faded blue bags, 4 dotted black bags. vibrant plum bags contain 5 faded blue bags, 6 dotted black bags. faded blue bags contain no other bags. dotted black bags contain no other bags.

It took a hot minute.

Try several weeks.

Well, yeah. I got to contribute to a bunch of open-source projects in the meantime though, so I’m fairly pleased with it!

• libffi (for static linking)
• cairo (more static linking!)
• proxy-libintl (more static linking!)
• expat (static linking strikes again)
• poppler (for file descriptor stuff not properly gated on Windows, closed in favor of a similar MR)

It’s time for the Day 14 problem!

After the hassle that was Day 13, I hope this time we’ll have a relatively chill time. And, at least for Part 1, that is true.

Our input looks something like this:

mask = XXXXXXXXXXXXXXXXXXXXXXXXXXXXX1XXXX0X mem[8] = 11 mem[7] = 101 mem[8] = 0

mem is our memory. Our addresses are 36-bit wide, but as you’ll see, that doesn’t matter much.

There’s one thing that bothers me. In part 1, why are we using hyper-staticfile? Couldn’t we just use file:/// URLs?

Well, first off: showing off how easy it is to serve some static files, even in a “scary” language like Rust, is just not something I could pass up.

But also: think about distributing salvage as a tool. Will we want to distribute all those HTML/CSS/JS/font files alongside it?

Let’s tackle the day 16 puzzle!

Parsing

The input looks like this:

Valve AA has flow rate=0; tunnels lead to valves DD, II, BB Valve BB has flow rate=13; tunnels lead to valves CC, AA Valve CC has flow rate=2; tunnels lead to valves DD, BB Valve DD has flow rate=20; tunnels lead to valves CC, AA, EE Valve EE has flow rate=3; tunnels lead to valves FF, DD Valve FF has flow rate=0; tunnels lead to valves EE, GG Valve GG has flow rate=0; tunnels lead to valves FF, HH Valve HH has flow rate=22; tunnel leads to valve GG Valve II has flow rate=0; tunnels lead to valves AA, JJ Valve JJ has flow rate=21; tunnel leads to valve II

The day 15 puzzle falls into the “math puzzle” territory more than “let’s learn something new about Rust”, but since several folks asked if I was going to continue… let’s continue.

The sample input is as follows:

Sensor at x=2, y=18: closest beacon is at x=-2, y=15 Sensor at x=9, y=16: closest beacon is at x=10, y=16 Sensor at x=13, y=2: closest beacon is at x=15, y=3 Sensor at x=12, y=14: closest beacon is at x=10, y=16 Sensor at x=10, y=20: closest beacon is at x=10, y=16 Sensor at x=14, y=17: closest beacon is at x=10, y=16 Sensor at x=8, y=7: closest beacon is at x=2, y=10 Sensor at x=2, y=0: closest beacon is at x=2, y=10 Sensor at x=0, y=11: closest beacon is at x=2, y=10 Sensor at x=20, y=14: closest beacon is at x=25, y=17 Sensor at x=17, y=20: closest beacon is at x=21, y=22 Sensor at x=16, y=7: closest beacon is at x=15, y=3 Sensor at x=14, y=3: closest beacon is at x=15, y=3 Sensor at x=20, y=1: closest beacon is at x=15, y=3

Documentation in ooc land has sucked for quite some time. The standard response is pretty much: “use the code, Luke!” — which is fine when doing small projects that don’t matter much, but not so when you want to get serious.

So when a newcomer, beoran, asked how to generate documentation, and later told us he got NaturalDocs to work, naturally, I had to see for myself how well it worked.

So far, we’ve seen many ways to read a file from different programming languages, we’ve learned about syscalls, how to make those from assembly, then we’ve learned about memory mapping, virtual address spaces, and generally some of the mechanisms in which userland and the kernel interact.

But in our exploration, we’ve always considered the kernel more or less like a “black box”. It’s time to change that.

With the previous part’s VM still running, let’s try connecting to our machine over SSH.

Network addresses, loopback and IP nets

Normally, to connect to a machine, you’d find its IP address. On Linux, a decade ago, you would’ve used ifconfig. Nowadays you can use ip addr:

The loopback interface (lo) is local, so it’s not useful to reach the box from the outside: you can see it can be accessed over IPv4 at address 127.0.0.1 but not just! What we’re reading here is 127.0.0.1/8, which corresponds to the range 127.0.0.1 - 127.255.255.255

It’s refactor time!

Our complete program is now about a hundred lines, counting blank lines (see the end of part 3 for a complete listing).

While this is pretty good for a zero-dependency project (save for pretty-hex), we can do better.

First off, concerns are mixed up. In the same file, we:

• Expose LoadLibraryA / GetProcAddress
• Expose the Win32 ICMP API