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

31–40 of 66 posts

Re: C considered dangerous

#31

Post by maccard »

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.

That only eliminates a certain case of bugs. There are still plenty of foot-shotguns available - memcpy/memset, strlen, gets/puts, printf, any file IO, networking calls, etc.

Re: C considered dangerous

#32

Post by pjmlp »

AlotOfReading wrote: post #21
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.

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.

The alternatives were there before UNIX took over server room and workstation market.

Just imagine how many millions the IT industry and PhD research have spent developing solutions that would improve C's safety, many of them largely ignored by most C developers.

Re: C considered dangerous

#33

Post by vardump »

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

Re: C considered dangerous

#34

Post by pjmlp »

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.

Good luck ensuring that doesn't trigger UB across all target architectures and compilers being used.

Re: C considered dangerous

#37

Post by vardump »

pjmlp wrote: post #34
vardump wrote: post #33

Earlier quoted context omitted.

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.

Good luck ensuring that doesn't trigger UB across all target architectures and compilers being used.

I agree, but that's besides the point.

It was just an example to show one way how C can control alignment.

Re: C considered dangerous

#39

Post by deng »

Thankfully, compiler warnings and static analyzers have become much better in recent years. For instance, gcc can now warn about a missing 'break;' mentioned in the article (you need to add a special comment like '/* fall through */' if it's intentional). Also, clang-tidy is getting better with each release. I highly recommend using it, although the initial configuration will take some time, depending on the code base.

Re: C considered dangerous

#40

Post by xroche »

Alas! strlcpy and strlcat are still not present in the glibc, despite numerous attempts, mainly for religious reasons (ie. "BSD sucks").

And yes, having something like "if (strlcat(buffer, src, sizeof(buffer) >= sizeof(buffer)) { abort(); } " is much better than buffer overrun. But security does not always seem to be a real concern, compared to politics.

Post reply on HN