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

C considered dangerous

lwn.net

Post reply on HN
Print view View original

21–30 of 66 posts

Re: C considered dangerous

#21

Post by AlotOfReading »

vardump wrote: post #5
fithisux wrote: post #2

The title is completely misleading.

I write a ton of C and I completely agree with the title. With 20+ years of experience. Kernel drivers and embedded system bare metal firmware. The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests. And that something can lead to disastrous crashes and security vulnerabilities.

This is my view as well, from the same industry. However, the quality of the tools available in C to deal with its issues far exceed those in any other language. I would love to drop C from all my systems, but the alternatives simply aren't there.

Re: C considered dangerous

#22

Post by raxxorrax »

vardump wrote: post #5
fithisux wrote: post #2

The title is completely misleading.

I write a ton of C and I completely agree with the title. With 20+ years of experience. Kernel drivers and embedded system bare metal firmware. The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests. And that something can lead to disastrous crashes and security vulnerabilities.

For embedded systems I mostly go with "dynamic memory allocation of any kind is evil" and that solves a lot of issues already.

You can still overwrite memory but it suddenly became much less likely.

Re: C considered dangerous

#23

Post by IshKebab »

Terrible title. It's not remotely news that C is dangerous. This talk seems to be about ways of mitigating the dangers. Why not call it "Mitigating the dangers of C" or something else that is less of a tired cliche?

Re: C considered dangerous

#24

Post by willtim »

vardump wrote: post #19
willtim wrote: post #17

Earlier quoted context omitted.

High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell has support for this). But this is a long way from having complete control how each memory heirarchy is used. Likewise most static languages defer to the compiler for CPU-specific performance optimisations and will permit foreign native calls into C or ASM where ne…

> High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell supports this). You often also need correct alignment. Cache-line or page. Your unboxed access across two pages can cause two TLB misses, L1 misses etc. Not to mention two page faults. Sometimes you need to ensure two (or more) buffers are NOT aligned in a partic…

The only support C is giving you for this is that it has sized unboxed types (and raw pointer access). Even then, you'd have to trust the compiler and take measurements to be sure.

Re: C considered dangerous

#25

Post by vardump »

raxxorrax wrote: post #22
vardump wrote: post #5

Earlier quoted context omitted.

I write a ton of C and I completely agree with the title. With 20+ years of experience. Kernel drivers and embedded system bare metal firmware. The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests. And that something can lead to disastrous crashes and security vulnerabilities.

For embedded systems I mostly go with "dynamic memory allocation of any kind is evil" and that solves a lot of issues already. You can still overwrite memory but it suddenly became much less likely.

> For embedded systems I mostly go with "dynamic memory allocation of any kind is evil" and that solves a lot of issues already.

Yeah, bare metal systems often don't allocate at all. Although one sin they often do commit is using same buffer for multiple purposes. What could go wrong...

Perhaps even more common is allocating a buffer on stack and writing past bounds somehow. Also DMA to/from stack is usually not a great idea...

Above things sound dumb, but can easily happen when you build your abstraction layers and use them carelessly.

Re: C considered dangerous

#26

Post by pjmlp »

FraKtus wrote: post #11
vardump wrote: post #5

Earlier quoted context omitted.

I write a ton of C and I completely agree with the title. With 20+ years of experience. Kernel drivers and embedded system bare metal firmware. The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests. And that something can lead to disastrous crashes and security vulnerabilities.

Don't you think that with the tools we have now it's easier to control the quality of code produced (Clang memory sanitizers and so on)? I feel more at ease to ship C code today after instrumenting it than a few years ago...

Not really, as it is proven almost on daily basis.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corr...

Re: C considered dangerous

#27

Post by simias »

aogl wrote: post #3
fithisux wrote: post #2

The title is completely misleading.

I agree, it's very click-baity. C is actually great and is only really dangerous because it gives the programmer so much control.

I'm a C coder first and foremost and I strongly disagree with this mentality (even though I know it's extremely pervasive in our circles). "Footguns don't make bugs, coders do" is technically true but if we could keep the footguns at a minimum and only get them out of the locker when truly necessary instead of having them spread all over the place all the time I'm sure it wouldn't hurt.

C is a very useful language and one you basically have to know if you're interested in low level software but it's very, very far from flawless.

If you look at many high profile software vulnerabilities of late (heartbleed, goto fail, etc...) many can be traced to the lack of safety and/or bad ergonomics of the C language.

We need to grow up as an industry and accept that using a seatbelt doesn't mean that you're a bad driver. Shit happens.

Re: C considered dangerous

#28

Post by pjmlp »

vardump wrote: post #15
FraKtus wrote: post #11

Earlier quoted context omitted.

Don't you think that with the tools we have now it's easier to control the quality of code produced (Clang memory sanitizers and so on)? I feel more at ease to ship C code today after instrumenting it than a few years ago...

Tooling absolutely helps to reduce defects. That's why you use them. That said, sometimes I'm shocked what kind of disasters get past the analyzers. Stakes are higher than ever. It's not just about functional correctness and avoiding crashes anymore. Your code needs to be secure against outside world malicious actions. Getting rid of counterintuitive security vulnerabilities is very, very hard.

I would say that is why security conscious developers use them.

Sadly we are a very very tiny percentage, as proven by Herb Sutter question to the audience at CppCon (1% of the audience answered positively), and CVE frequent updates.

Re: C considered dangerous

#29

Post by pjmlp »

yaris wrote: post #10
vardump wrote: post #5

Earlier quoted context omitted.

I write a ton of C and I completely agree with the title. With 20+ years of experience. Kernel drivers and embedded system bare metal firmware. The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests. And that something can lead to disastrous crashes and security vulnerabilities.

Well, I can say the same about Python, Erlang, Lua, in addition to C and C++. I believe C is not worse than these languages, only that C requires different (sometimes very different) skills and discipline.

Python, Erlang, Lua = Logic Errors

C and C++ = Logic Errors + Memory Corruption + UB

From this point of view,

Σ Logic Errors < Σ (Logic Errors + Memory Corruption + UB)

Re: C considered dangerous

#30

Post by pjmlp »

IshKebab wrote: post #23

Terrible title. It's not remotely news that C is dangerous. This talk seems to be about ways of mitigating the dangers. Why not call it "Mitigating the dangers of C" or something else that is less of a tired cliche?

Because "Making C Less Dangerous" is the actual title of the talk, and "Towards less dangerous C" is part of the agenda?
Post reply on HN