designing a suckless bignum library

Let's design a suckless bignum library. (I'm not part of suckless though, just curious about replacing GMP).

I researched a bit into algorithms and the rundown is this:
* long multiplication: O(n^2)
* karatsuba O(n^1.5)
* Toom-Cook, fourier transform based methods - even faster but only used for numbers 10k digits+ long. Much more complex.

So we should probably use karatsuba for all multiplications. Squaring can be done a bit faster than multiplying two different numbers sometimes.

Now I suggest programming it in assembly, that gives you access to the carry bit (C doesn't get you that). Of course we will use libc and the normal C calling conventions so that it's a regular C library.

What to do about memory management? e.g. if you want to add two numbers do we need to allocate a new 'number' as long as the largest to write the result into or do it destructively "x <- x + y"? Maybe the library should support both - then a calculator program would figure out the best primitives to use for a given computation.

It might be nice to also support things like (big modulus) modular arithmetic and polynomials. stuff like exponentiation and modular inverses have interesting algorithms.

What other integer operations would we want? I don't really want to do anything with arb. prec. real numbers - arithmetic with rationals could be done though.

the critical flaw in suckless is that they're trying to prevent bloat by optimizing for SLOC. this does prevent bloat but in a suboptimal way that sacrifices functionality and usability for user and maintainability (because muh SLOC limit) and readability (because a dirty deep magic hack can have less SLOC than a proper solution) for programmers.

for example, does anyone actually browse the web with surf? no, because it lacks features for actually browsing the web (that goes double for powerusers who like seeing source, inspecting or just having over 9000 tabs at the same time). rendering HTML is not enough.

the proper way of making a bloat-free project (especially hobby projects where you don't have corporate assholes with their deadline, changing requirements and le enterprise agile UML XML smart IOT buzzwords) would be a clearly defined scope (THE most important thing), a simple (preferably modular for easier maintenance) design and an adherence to good coding standards.

basically, aiming for low SLOC count makes sense only if you're doing code golf. if you want to make actually useful software, it should just be a rule of thumb