> This is why we don't use C - unsafe, unclear, unnecessary.
Actually, I think libbitcoin is using its own maintained fork of secp256k1, which is written in C.
We do not maintain secp256k1 code. For years that library carried the same version, despite regular breaking changes to its API. This compelled us to place these different versions on distinct git branches. When it finally became versioned we started phasing this unfortunate practice out.
Out of the 10 repositories and at least half million lines of code, apart from an embedded copy of qrencode that we don’t independently maintain, I believe there is only one .c file in use in the entire project - the database mmap.c implementation for msvc builds. This includes hash functions, with vectorization optimizations, etc.
For sure, I wouldn't recommend using C across a whole codebase as it's not memory-safe (euphemism) though it's still un-match if you wish to understand low-level memory management in hot paths.
This is a commonly held misperception.
It can be easier to use C++ or Rust, though it doesn't mean it will be as (a) perf optimal and (b) hardened against side-channels.
Rust has its own set of problems. No need to get into a language Jihad here. My point was to clarify that the particular question was not about a C (or C++) null pointer value, either on the surface or underneath an abstraction.
e