Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

141–150 of 388 posts

Re: The case against a C alternative

#141

Post by elihu »

dist1ll wrote: post #83
clysm wrote: post #13

> 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…

This is why I hope unikernels & Rust will eventually replace docker & linux for high-performance, high-security production deployments.

I agree. I think of address space context switching overhead as the performance price we pay for not being able to run all our programs in a single address space, which we could safely do if we knew all the programs were emitted by a trusted compiler that disallows unsafe memory access. Imagine if system calls were just ordinary functions that can be called with no more than the normal function call overhead? What if they could even be inlined?

Obviously there's a lot of little details you'd have to work out. Like how to make such a trusted compiler in the first place, and how to sandbox unsafe code and legacy applications that were compiled by an untrusted compiler.

If this seems like it's far-fetched or too much work, consider what lengths high-performance hardware devices like HPC network interfaces go to avoid system calls at all costs, to the point where applications talk to the hardware directly. Is that really a sustainable practice long term? And how can anyone audit the security of such hardware devices?

Re: The case against a C alternative

#142

Post by elihu »

bee_rider wrote: post #32
woodruffw wrote: post #26

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...

Think about web browsers. We're not really that worried about people running malicious web browsers. It's potentially a problem, but as long as people know not to run software that some random spammer sends them in an email then it's easy to avoid.

On the other hand what computer security people worry about a lot is that the web browsers made by reputable organizations and teams of competent programmers nevertheless contain security flaws that can be exploited by a maliciously-written website to cause those browsers to do unexpected and dangerous things.

Many of those security flaws in otherwise well-regarded software are due to memory management errors that just aren't present in safer languages, or they're due to type errors that wouldn't be present in more type-safe languages.

There are some implementation bugs that could be present in any language no matter how many safety features it has, but many security bugs aren't due to, say, an incorrectly specified algorithm, they're due to the programmer asking the computer to do something that's literally nonsense, like asking for the fourth element of a list that only has three elements, or recording that someone's age is apricot. Programming languages with powerful nonsense filters can remove a lot of those kinds of security bugs. (And powerful type systems often give programmers mechanisms to tell the compiler more about the program so that it can filter out more kinds of nonsense than it would otherwise.)

Re: The case against a C alternative

#143

Post by ducktective »

cogman10 wrote: post #62
User23 wrote: post #45

Earlier quoted context omitted.

> 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. 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…

> Please take a few days to review John Regehr’s excellent blog. Haven't heard of him but will certainly give a read. Thanks for the heads up. > Npm is the poster child for supply chain attacks. The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Hard to say that's really a plus. Other ecosyst…

>The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project.

Or the lack of canonical package manager means the developer has to actually spend time to inspect the quality of each dependency instead of `npm install is-odd`ing like there is no tomorrow.

It also acts as a "filter" to prevent adding complexity to the dependency tree.

Re: The case against a C alternative

#144

Post by gregoryc_ »

jitl wrote: post #93
gregoryc_ wrote: post #38

The simplest solution is a preprocessor. The original founders of C made one, probably because they needed it. But adding another lightweight one is simple. C++ has bloat. Compilation time can be slow. I realize that this is radical, but if people could work with me on this, this could solve all your problems, no really, it could solve all your problems. And if it can't solve all your problems yet, then modify it to…

Is your thing on GitHub?

I just made a github.

Re: The case against a C alternative

#145

Post by gregoryc_ »

joeldo wrote: post #115
gregoryc_ wrote: post #29

Has anyone checked out this? You can use C, but with better syntax. https://cboard.cprogramming.com/c-programming/181160-hi-i-ha... I'm looking for contributors. :)

Just some advice, I think you'll struggle to gain traction without putting the source onto Github, as that is generally how people contribute :)

I just made a github.

https://github.com/gregoryc/EmeraldC/

Re: The case against a C alternative

#146

Post by gregoryc_ »

jitl wrote: post #93
gregoryc_ wrote: post #38

The simplest solution is a preprocessor. The original founders of C made one, probably because they needed it. But adding another lightweight one is simple. C++ has bloat. Compilation time can be slow. I realize that this is radical, but if people could work with me on this, this could solve all your problems, no really, it could solve all your problems. And if it can't solve all your problems yet, then modify it to…

Is your thing on GitHub?

https://github.com/gregoryc/EmeraldC/

Re: The case against a C alternative

#147

Post by speed_spread »

carey wrote: post #85
speed_spread wrote: post #65

Earlier quoted context omitted.

> trying to write new code for IBM RPG servers Hey, I know that! Challenge accep... Eeeeh, nevermind.

All the modern AS/400 servers can run unmodified AIX programs these days anyway.

You keep enumerating words that I will never put in my CV lest employers know that I have been paid to suffer at their contact.

Re: The case against a C alternative

#148

Post by Gibbon1 »

elcomet wrote: post #49
lisper wrote: post #22

Earlier quoted context omitted.

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.

That's not the point. The point the parent is making is that yes, languages that include safety features are slower, but you will actually need those safety features in C as well, in the code. So your program will also be slower in C.

There is something backwards about how safety checks are done in C.

First it's up to the programmer to put them in. Then hopefully the compiler will optimize away the unneeded ones. If the programmer though biffs and forgets then oops. And of course classically we blame the programmer not the system he's been forced to work under.

That seems like a reasonable thing in 1982. Which is 40 years ago.

It would be better if the compiler implemented the checks automagically and removed ones it knows it doesn't need. And bonus, if the programmer puts one in, leave it alone.

Re: The case against a C alternative

#149

Post by hobofan »

pkrumins wrote: post #94
woodruffw wrote: post #40

> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. I don't think this is true, in the general case: Rust has shown that languages…

Quoted post unavailable.

Why do you keep posting this? One would think by the 10th heavily downvoted comment in the same vein you would have figured out by now that the flaming is neither clever nor appreciated.

Re: The case against a C alternative

#150

Post by pjmlp »

woodruffw wrote: post #40

> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. I don't think this is true, in the general case: Rust has shown that languages…

Additionally, back in the 8 and 16 bit home computer days, C programms were full of inline Assembly, because C compilers generated garbage machine code.

It was 40 years of throwing UB optimizations at it, that made its current performance come true.

This is nothing special, any language can eventually reach that reality with similar investment.

Post reply on HN