C# or C/C++ code to convert Bitcoin brainwallet to public address

[PowerGlove]

(...) To put it this way: if the average practitioner wants to write a program with 256-bit integers, and acknowledges he's incapable of maintaining that in C, won't he just switch to an alternative, like Python?

Yep, I'm with you. But, it's worth thinking about where basing decisions on a criterion like that will eventually lead, no?

Adding things to C out of fear that people might otherwise abandon it for an easier language will (over time) turn the spec into a real mess...

Each decision in isolation seems justifiable, but in the limit, they'll eat C from the inside out and turn it into a language with no clear vision and no well-defined purpose.

I think it's worth reflecting on just how much can be (and has been) accomplished with C89. If you compare the "complexity" of C89 to its "expressive power" (just as an abstract exercise, don't think too deeply about defining those terms, or their units, etc.) you'll find that it hits a kind of magical sweet spot (same thing is true, and in an even more compelling way, for Forth and Lisp). The old guard really knew what they were doing, and every programmer I admire "gets" C (even if they no longer use it) in a way that most modern programmers don't (or maybe can't).

Humanity seems to agree that things should always be changing, but in my experience, this appetite for improvement presents most strongly in people that don't actually know what they're doing.

(Don't take anything I've said personally, none of my dismissive commentary is directed at you, I'm just sharing my thoughts.)

[pooya87]

Sure, it's possible, but to rephrase my question: why isn't it standard already? I mean, the last C standard was published in 2017, long after Big Integers became a need. And still, the largest standard integer you can define is 64-bits long.

I suppose it is because of hardware limitations. We haven't really improved a lot of things in CPUs, x64 was released 30 years ago and there is no x128 on the horizons or for example core speed (clock rate) hasn't really improved for decades (we just get more cores to have faster CPU).
Our hardware simply can not handle integers bigger than 64-bit (no bigger registers). So it has to be implemented using smaller chunks which is what loads of existing math/arithmetic libraries do so I don't think the standard itself needs to have them.

However, many languages have added the bigger integer types. You already know the one in C++, there is also Int128 in dotnet. It took them 7 version of core and at least 5 years to implement it and as you can see it doesn't do anything special, it uses 2 UInt64 limbs and the arithmetic is a bunch of branches handling the overflow which is not the fastest thing.

[BlackHatCoiner]

Yep, I'm with you. But, it's worth thinking about where basing decisions on a criterion like that will eventually lead, no?

Absolutely. So in which criterion was lack of more than 64-bit guaranteed data type based on, in C89? At the time of publishing that standard (1989), one could argue problems didn't need more than that integer size, or it may have been unusable with processors of that time (I think MIPS32 and MIPS64 were popular in the early 90's, none of which could handle more than 64 bits number). And as I'm reading pooya's reply, we haven't exceeded that on the newest processors neither.