Type safety and encapsulation are distinct issues. The Linux kernel uses many well-encapsulated interfaces but it's written in C and the typing reflects that limitation.

Personally I haven't used straight C in years and would never choose it over C++ unless platform constraints required it, but a vast amount of very complex software has been and continues to be written in C, including all the widely used OS kernels, so I don't find it very surprising that a new feature in a very old piece of software would be written in it.

Except when you need to build from source; you'll need yet another whole compiler toolchain that may or may not behave well on a specific environment - eg, do you kow how well rust (or other "modern" language) works in late-nineties mips systems? The c compiler is the lowest common denominator.

Code from yalsat (stochastic SAT solver) [1] made me learn something two years ago. I can declare an array of some elements and make access to elements statically typed. Same with maps, sets and others.

[1] https://github.com/msoos/yalsat/blob/main/yals.c#L49

this is a pointer-based language so there are lots of ways to solve that, but you know that already.. this is a setup question.. of course its not useful to re-invent critical, secure functions over and over yet, what if I am not writing critical, secure functions anyway?

I would choose a key type that is natural to the environment and problem.. unsigned integers are useful. Which unsigned integer size? there are only a couple of practical answers to that.. unless there is some massive dataset, use a 32bit unsigned integer, like so much of the software does right now.

size_t key_size, void *key