OK, you just said you've used packed nybble arrays a couple of times.
Multiplying you by 100,000 that proves if you put it in GCC,
you'd save 200,000 programmer hours, which is equivalent to saving
over 2 lives.
You just said you've written your own double-length multiply.
Same proof.
Thank you for proving my point.
How many deaths does it take before it is worth putting into GCC?
And it isn't like I'm suggesting something hard, or which would be
unattractive to users.
And thanks for the tip on how to do add-with-carry.
That's nice. Now I have to ask, now you've helpfully demonstrated
how nice it can be, why not put that niceness inside GCC? I mean, if
GCC already is going to
provide div(a,b) -- it was not me who asked for that, it was GCC that
decided to provide it --
which I could have just got in plain C using q=a/b; r=a%b; and depended on
optimizer, zero thought required -- then how can just justify GCC
*not* providing addc(a,b) when it is trickier for the programmer, so
you are clearly providing something more helpful since was more
tricky?
Why am I bothering? You prove my point then act as though you proved opposite.
Concrete examples? Hell, I suggested stdint.h years and years before
it came along, and I was told I was an idiot. I suggested making a
lot of library functions be builtins, told I was an idiot, and now lo
and behold, years and years later, gcc makes many library functions be
builtins. I complained the stdio library was a disaster waiting to
happen with
buffer overflows, told I was an idiot, and lo and behold, years and
years later people keep trying to work around that, with at least two
people having written nonstandard replacement libraries to try for
safety, and huge billions of dollars estimated to be lost due to this
bad design.
Concerning suggestions I've made that never were adopted, I would like
C to have array-bounds checking available as a compiler option.
Also profiling.
I'd like elsif. I'd like more sophisticated compile time stuff, like right now
they have #if, #elsif, #endif. Ok, why not #for? That way we could unroll
loops by "doing the loop at compile time" not runtime. (Need to make
a language subset intentionally weakened to not be turing complete, i.e. we
want to know for sure the compile always will terminate, but still
precompiler language could be a good deal more powerful than now.) I
could discuss that.
I'd like a compile-time language giving you a fair amount of power, but
below turing-power, and
acting as though it were sensibly designed in from start with similar syntax
(within reason) to the actual runtime language -- not intentionally
different syntax for no reason aside from trying to annoy people, and
not an obvious crude add-on.
I'd like different parts of my program to be optimized for space, or
for speed -- I get to say for which parts I want which using pragmas.
I'd like addons to support
multiple entry points for routines easy, so I can make coroutines and
"iterators."
(This can be done with present C, but it seems a much bigger pain than
it needs to be.)
Pointer arithmetic is a well known disaster-waiting-to-happen in C,
but of course there are compensating performance benefits... but
you could get the best of both worlds with ability to declare "safe"
pointers e.g. with bounds checking of them added by compiler and the bounds
created when the pointer is. Such safety could be turned off with a
compiler option for more speed. Point is, C arrays and pointers are
very unsafe for a few reasons, but by
adding some compiler options and/or language extensions to allow
adding safe versions
of that stuff, GCC could make it a lot easier on programmers to get a
lot safer with
near zero effort.
But hey, nearly all those ideas actually require work, meanwhile I
think uint4_t is
nearly trivial by comparison.