C considered dangerous

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.

Re: C considered dangerous

#6

Post by rwmj » Thu, Aug 30, 2018, 7:35 AM UTC

> He asked: why is there no argument to memcpy() to specify the maximum destination length?

I'm confused by this. The third argument provides the destination length, so what good would a "maximum destination length" do? I guess he must mean that because the length is often computed, you'd need a fourth argument to ensure the length isn't greater than some sane upper bound. But you can easily fix that using an if statement around the memcpy.

Re: C considered dangerous

#7

Post by willtim » Thu, Aug 30, 2018, 7:39 AM UTC

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.

C actually gives one rather limited control over modern hardware with it's memory hierarchies and superscaler CPUs. Programming language research has also moved on a lot since the 70's, which is why we should be considering less dangerous languages (e.g. better type systems and less undefined behaviour). Languages like ATS and Rust also support explicit memory management, whilst being a whole lot safer.

Re: C considered dangerous

#8

Post by vardump » Thu, Aug 30, 2018, 7:40 AM UTC

rwmj wrote: post #6

> He asked: why is there no argument to memcpy() to specify the maximum destination length? I'm confused by this. The third argument provides the destination length, so what good would a "maximum destination length" do? I guess he must mean that because the length is often computed, you'd need a fourth argument to ensure the length isn't greater than some sane upper bound. But you can easily fix that using an if stat…

Perhaps because the memory buffers might be of different size.

Maybe memcpy_oobp (out of bounds protection) signature could be:

  memcpy_oobp(void* dst, size_t dst_size, void* src, size_t src_size);

Then again, I guess you could just as well do:

  memcpy(dst, src, min(dst_size, src_size));

But having to explicitly specify both destination and source sizes might have prevented a lot of buffer overwrite bugs.

Re: C considered dangerous

#9

Post by buboard » Thu, Aug 30, 2018, 7:43 AM UTC

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.

"Programmers using C are considered dangerous"

Re: C considered dangerous

#10

Post by yaris » Thu, Aug 30, 2018, 7:44 AM UTC

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.

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.