Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival

From: Eric Voskuil <[email-masked]>
Date: Thu, 4 Jul 2024 07:45:59 -0700 (PDT)

> 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 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a76b8dc5-d37f-4059-882b-207004874887n%40googlegroups.com.