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

51–60 of 388 posts

Re: The case against a C alternative

#51

Post by mattnewton »

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

The language the innocent programs are written in can remove attack vectors that the malicious programs use; I don’t think it matters what the malicious programs are written in?

Re: The case against a C alternative

#52

Post by Jtsummers »

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

It would prevent or at least mitigate some classes of exploitation. Buffer overflows are very common attack vectors: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+over... (386 results, 11 from prior years, so 375 from this year). 23 of those are in kernels, many leading to privilege escalation.

Re: The case against a C alternative

#53

Post by pshc »

gregoryc_ wrote: post #47
pshc wrote: post #41

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.

Depends on the functions used. memcpy is better than strcpy

I’m sure you meant something more along the lines of “strncpy is better than strcpy”.

Re: The case against a C alternative

#54

Post by ryandrake »

lisper wrote: post #22
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…

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.

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

To be devil’s advocate and take the other side of this argument: I would rather the CPU I paid for spend its cycles performing actual application logic. Every cycle spent executing all this “safety code” overhead feels like me having to pay for a developer’s sloppiness.

I feel end users pay a high cost for all this runtime checking and all these frameworks and levels of abstraction.

Re: The case against a C alternative

#55

Post by lisper »

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.

Yes, I think we're actually all in agreement here. The common point is that TFA's argument that we need to keep C because it's faster is invalid. The GP's point is that it is not in fact faster because of all the things you need to do to produce code that can actually be deployed in today's world. My point is that even if C were faster (which it actually isn't) that would not matter because C is unsafe even with all the extra stuff that people stick onto it to try to make it safe. So the original claim is really a judgement call that speed matters more than safety, and this is not something about which there is any kind of consensus.

Re: The case against a C alternative

#56

Post by chaeronanaut »

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…

this pretty much summarises my opinion - one nitpick - i assume you meant "omit bounds and other checks", not "emit bounds and other checks" which seems to mean the opposite of what you're intending

Re: The case against a C alternative

#57

Post by [deleted] »

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…

[deleted]

Re: The case against a C alternative

#59

Post by woodruffw »

chaeronanaut wrote: post #56
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…

this pretty much summarises my opinion - one nitpick - i assume you meant " omit bounds and other checks", not "emit bounds and other checks" which seems to mean the opposite of what you're intending

Yes, thank you! That's an embarrassing typo!

(And thanks to the other person as well, who presumably deleted the same comment after seeing yours.)

Re: The case against a C alternative

#60

Post by jiggawatts »

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…

Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language.

For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performance cliffs due to O(n^2) algorithms all over the place. Why not hashtables? Because they're not generic, so they're a pain to use. Not impossible of course, it's just that C developers avoid them.

Similarly, "strongly typed" containers full of simple struct types enable compiler auto-vectorisation that's often unavailable in C for the same kind of reason.

Last but not least, you would have to be a masochist to write heavily multi-threaded code in C... so hardly anybody does. These days, that's throwing away over 90% of the computer power in a typical PC, let alone a server.

Post reply on HN