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

41–50 of 66 posts

Re: C considered dangerous

#41

Post by millstone »

willtim wrote: post #7
aogl wrote: post #3

Earlier quoted context omitted.

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.

Are you suggesting that other languages provide more control over modern hardware?

Re: C considered dangerous

#44

Post by jcelerier »

pjmlp wrote: post #29
yaris wrote: post #10

Earlier quoted context omitted.

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)

hmmm... In my experience, I have had much less logic errors in C++ than in Python or JS because I tend to try to encode the domain logic into the types as much as possible, so that I can piggyback on the compiler.

Re: C considered dangerous

#45

Post by unwind »

willtim wrote: post #24
vardump wrote: post #19

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

That's not true, since C11 we have:

    #include 

    void *aligned_alloc(size_t alignment, size_t size);
which works like malloc() but lets you specify the required alignment.

Re: C considered dangerous

#46

Post by willtim »

unwind wrote: post #45
willtim wrote: post #24

Earlier quoted context omitted.

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.

That's not true, since C11 we have: #include void *aligned_alloc(size_t alignment, size_t size); which works like malloc() but lets you specify the required alignment.

Could I not just call such a function from my alternative language?

Re: C considered dangerous

#47

Post by yason »

C is dangerous partly because assembly language is dangerous. We will always need some layer on top of assembly that is mostly unchecked and reflects back to how cpu instructions work. This is probably something we must live with until we have processors with the notion of type checking.

C is dangerous partly because of swaths of undefined behaviour and loose typing. Eliminating much of undefined behaviour either by defining the behaviour or forcing the compiler to refuse compile undefined behaviour could be of some help. There are still classes of undefined behaviour that cannot be worked around but narrowing that down to a minimal set would make it easier to deal with it. Strong typing would help build programs that won't compile unless they are correct at least in terms of types of values.

C is dangerous partly because of the stupid standard library which isn't necessarily a core language problem as other libraries can be used. The standard library should be replaced with any of the sane libraries that different projects have written for themselves to avoid using libc. It's perfectly possible not to have memcpy() or strcpy() like minefields or strtok() or strtol() which introduce the nice invisible access to internal static storage, fixed by a re-entrant variant like strtok_r(), or require you to do multiple checks to determine how the function actually failed. The problem here is that if there are X standards, adding one to replace them all will make it X+1 standards.

Yet, good programmers already avoid 99% of the problems by manually policing themselves. For them, C is simple, productive, and manageable in a lot more cases and domains than it is for the less experienced programmers.

Re: C considered dangerous

#48

Post by willtim »

vardump wrote: post #33
willtim wrote: post #24

Earlier quoted context omitted.

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.

That's not true. You can also control data alignment in various ways. For example, you don't need to write to the beginning of an allocated buffer, but skip to the point where low order address bits are what you want. Something like this for example: char* aligned_buf; char* buf; size_t max_align_offset = (1 In the example, if align==8, you have 256 byte alignment. If it's 12, 4kB alignment.

This example looks like it should be turned into a malloc variant, i.e. needs only to be written once. Raw pointer access is also available in other languages of course, albeit it is usually made much more difficult.

Re: C considered dangerous

#49

Post by abainbridge »

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.

> The problem with C is that in any bigger project something always slips through even the best programmers, reviewers, static analysis and unit tests.

That's also true of all the other languages.

Re: C considered dangerous

#50

Post by MrBuddyCasino »

vardump wrote: post #25
raxxorrax wrote: post #22

Earlier quoted context omitted.

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

> DMA to/from stack

wait what oh my god

Post reply on HN