21–30 of 388 posts
(5) is pretty irrelevant, ABI isn't language. You can strap basically any language on top of the C ABI. Many contender languages either use it natively or offer low-cost/no-cost C ABI bindings, specifically as its the lingua franca ABI. You can check (5) off your list if your choice of replacement language has easy C ABI interop. [edit] (1) isn't particularly relevant either. These days the tooling for detecting memo…
> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. And what is the runtime cost of all the mitigations put in place because we don't use a memory safe language ? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level…
> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. And what is the runtime cost of all the mitigations put in place because we don't use a memory safe language ? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level…
I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler.
However, that's hardly something most devs will care about. At this point, we are pretty much all targeting Arm or x86 (Sorry PIC and MIPS devs). And every new language that's cropped up at a minimum supports both those platforms and the major OSes for those platforms.
So once you dismiss that point, what are you left with? Tools for catching memory leaks? Well, sorry, but pretty much every language has those tools and better. Particularly GCed languages. Profiling tools? Debug tools? To say the C debug tools are "good" is to say you've not used any other toolchain.
But let's also point out C's horror story that is "dependency management and building". How do you grab dependencies for and build javascript? npm install, npm build. How about C? Well... are you using auto tools? Cmake? Ninja? Scion? makefiles? etc... Oh, and how do you get dependencies? Well, hope you like reading readme files and decipher cryptic "symbol not found xyz" compiler errors.
Suffice it to say C's toolchain isn't anything to be proud of. It's a relic of the 70s that to this day gets in the way because the community has practically given up on the idea of fixing the glaring issues (Too hard, everything already depends on X working the way X does).
So why risk switching languages? Well, because the C toolchain is a dumpster fire and you likely aren't trying to write new code for IBM RPG servers.
> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. And what is the runtime cost of all the mitigations put in place because we don't use a memory safe language ? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level…
You are the security engineer, so you certainly know better than me, but aren't those runtime mitigations aimed at malicious programs? Which is to say, even if a better-C was written that didn't allow people to write a program that would bump into those mitigations, the bad guys could still write their programs in assembly or C or whatever, right?
Wow, this blog entry's reasoning is a leaky ship. 1. C language toolchain -- No specifics (save static analyzers, ... because C needs static analyzers to catch C specific bugs...). What do you actually feel you're missing? Most of these "new C" languages use the same backend as a C compiler. What can't you use? 2., 3., and 4. -- Just chicken and egg FUD. Not to mention it's "'Better X' doesn't matter" fundamentally d…
It's a position paper meant to sketch out the negative space that a viable C replacement can't meaningfully compete in, so that its designers can focus attention on things that actually add value. If you don't acknowledge your enemy's strengths, you'll never really be able to fight them.
You can use C, but with better syntax.
https://cboard.cprogramming.com/c-programming/181160-hi-i-ha...
I'm looking for contributors. :)
> [...] Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register.
This reminds me of Amdahl's Law [1], about how a performance optimization (parallelism) has small returns because the performance improvement only affects a small portion of the overall process.