41–50 of 388 posts
> Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized.
Such a handwavy deflection. Parsing strings in C is a joke and also a minefield bursting with vulnerabilities. And if you use null terminated strings (which you are, let’s face it) it’s slow.
Earlier quoted context omitted.
> What do you actually feel you're missing? It explicitly says in the post... for example static analyzers. What is the "Frama-C" equivalent of any language that bills itself as a replacement / competitor of C? > Most of these "new C" languages use the same backend as a C compiler. Most of them use LLVM as far as I know, which does not target plenty of obscure platforms.
So the argument is we need the bug finders we've developed for C (because our C is full of bugs)? > Most of them use LLVM as far as I know, which does not target plenty of obscure platforms. Yeah, writing software in the old language is more convenient on obscure, rare, niche platforms, because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right?
It seems like you're being needlessly hostile. There is nothing personal about this discussion, and it's not nonsense. I write embedded software that needs to run on PIC18 microcontrollers. Support for that in LLVM was dropped about 8 years ago. Do you think it's reasonable to say to someone "just add a new LLVM target, it's not literally impossible"?
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…
I would reread the first paragraph. In context, this is clearly not an "anti-Rust/pro-C" essay. It's not a championing of C nor a resignation to its perpetual dominance. 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'…
Yeah, I get it and I'm not sure it does that job well enough to be taken seriously.
Earlier quoted context omitted.
They're aimed at protecting innocent programs from exploitation. If we knew which programs were actually malicious, our lives would be much easier!
But the presence of a better language to write innocent programs in wouldn't protect the innocent programs from malicious programs written in C and assembly...
> C language toolchain 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…
Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding.
> How do you grab dependencies for and build javascript? npm install, npm build.
Npm is the poster child for supply chain attacks.
Is there a "standard C" llvm target? That would maybe chip away at the "if you are working on some obscure embedded platform, C might be the only supported high level language" advantage.
This article is just apologism for the status quo. Nothing new here. > Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized. Such a handwavy deflection. Parsing strings in C is a joke and also a minefield bursting with vulnerabilities. And if you use null terminated strings (which you are, let’s face it) it’s slow.
Earlier quoted context omitted.
They're aimed at protecting innocent programs from exploitation. If we knew which programs were actually malicious, our lives would be much easier!
But the presence of a better language to write innocent programs in wouldn't protect the innocent programs from malicious programs written in C and assembly...
Runtime mitigations exist to mitigate some of the latent risk associated with programming in unsafe programming languages. We use them because they're our best known approach to continuing to use those languages without letting script kiddies own us like it's 1993.
> 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…
And who says that faster runtime trumps all other considerations? I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time.
Earlier quoted context omitted.
So the argument is we need the bug finders we've developed for C (because our C is full of bugs)? > Most of them use LLVM as far as I know, which does not target plenty of obscure platforms. Yeah, writing software in the old language is more convenient on obscure, rare, niche platforms, because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right?
> Yeah, writing software in the old language is more convenient because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right? It seems like you're being needlessly hostile. There is nothing personal about this discussion, and it's not nonsense. I write embedded software that needs to run on PIC18 microcontrollers. Support for that in LLVM was dropped abou…
I'm profoundly disappointed. This article's reasoning is not good.
> Do you think it's reasonable to say to someone "just add a new LLVM target, it's not literally impossible"?
No, but that C is already pervasive because it's been around 50 years isn't a case "against an alternative to C" as much as it is a headwind. That's fair. C has a massive head start and no one should discount that. But I'm not exactly certain that was the argument he was making.