3 ms·

> C is not a safe language. It what ways is it unsafe? Thinking about the examples you'll cite, can the programmer introduce checks and safety nets to overcome

by movedx 10y ago

> C is not a safe language. It what ways is it unsafe? Thinking about the examples you'll cite, can the programmer introduce checks and safety nets to overcome them? For example, you'll no doubt mention buffer overflows, but can these be protected against?

Jweb_Guru 10y ago
With multiple threads, detecting UB is undecidable (as seen in https://www.ideals.illinois.edu/bitstream/handle/2142/30780/ellison-rosu-2012-tr.pdf?sequence=2 https://www.ideals.illinois.edu/bitstream/handle/2142/30780/...). If you ignore the weirdest UB and are willing to eat a lot of performance at runtime there is probably a conservative version that works though (there is for sure in the single-threaded case, e.g. see http://robbertkrebbers.nl/research/thesis.pdf http://robbertkrebbers.nl/research/thesis.pdf).
geofft 10y ago
Yes, it is possible to build checks and safety nets to overcome them. But it isn't easy. The simplest example here is the one the Safe C Library is about: it's very hard in C to talk about memory buffers that know their own capacity. C wants you to think about pointers, often with implicit lengths (memcpy takes a single size parameter, strcpy takes none, tmpname takes none, etc.). You can write a library where you pass lengths alongside every pointer. But you've got to keep track of two variables for what should conceptually be a single variable. Now, one approach is to make a struct buffer {char *ptr; size_t len;}. But then you run into C's problem that it has no encapsulation or operator overloading. You can't index into a buffer; you can call a function that checks the length, or you can just do the tempting thing of ->ptr[i], which you'll get wrong at some point. The compiler won't help you notice that you got it wrong. And even if you do that, the C standard library is full of the unsafe approach to pointers. If you scrupulously avoid all functions that use unsafe pointers, you've also got to avoid the C standard library as well as almost all third-party libraries. This is not what most people think of when they think of using C. C++ (and especially C++11 with good discipline) is a very good step forward in the direction of making C more safe, in no small part because C++ has its own standard library and the entire ecosystem tends to use that standard library. Due to the desire to be backwards-compatible with C, C++ retains a lot of unsafety, but it makes safer paradigms possible. If you're not bound to backwards-compatibility, though, there's probably no reason to voluntarily take the burden of dealing with the things that are unsafe in C.
- cvwright 10y ago
  > Now, one approach is to make a struct buffer {char ptr; size_t len;}. A "fat" pointer. That's essentially what the Cello project does [1]. The author has pulled together some crazy hacks to make this approach accessible in C. Including, apparently his own version of many standard library routines. Crazy, but very interesting. Discussed on HN yesterday/today: https://news.ycombinator.com/item?id=14091630 https://news.ycombinator.com/item?id=14091630 [1] http://libcello.org/learn/a-fat-pointer-library http://libcello.org/learn/a-fat-pointer-library

by movedx 10y ago

Jweb_Guru 10y ago

With multiple threads, detecting UB is undecidable (as seen in https://www.ideals.illinois.edu/bitstream/handle/2142/30780/ellison-rosu-2012-tr.pdf?sequence=2 https://www.ideals.illinois.edu/bitstream/handle/2142/30780/...). If you ignore the weirdest UB and are willing to eat a lot of performance at runtime there is probably a conservative version that works though (there is for sure in the single-threaded case, e.g. see http://robbertkrebbers.nl/research/thesis.pdf http://robbertkrebbers.nl/research/thesis.pdf).

geofft 10y ago

Yes, it is possible to build checks and safety nets to overcome them. But it isn't easy. The simplest example here is the one the Safe C Library is about: it's very hard in C to talk about memory buffers that know their own capacity. C wants you to think about pointers, often with implicit lengths (memcpy takes a single size parameter, strcpy takes none, tmpname takes none, etc.). You can write a library where you pass lengths alongside every pointer. But you've got to keep track of two variables for what should conceptually be a single variable. Now, one approach is to make a struct buffer {char *ptr; size_t len;}. But then you run into C's problem that it has no encapsulation or operator overloading. You can't index into a buffer; you can call a function that checks the length, or you can just do the tempting thing of ->ptr[i], which you'll get wrong at some point. The compiler won't help you notice that you got it wrong. And even if you do that, the C standard library is full of the unsafe approach to pointers. If you scrupulously avoid all functions that use unsafe pointers, you've also got to avoid the C standard library as well as almost all third-party libraries. This is not what most people think of when they think of using C. C++ (and especially C++11 with good discipline) is a very good step forward in the direction of making C more safe, in no small part because C++ has its own standard library and the entire ecosystem tends to use that standard library. Due to the desire to be backwards-compatible with C, C++ retains a lot of unsafety, but it makes safer paradigms possible. If you're not bound to backwards-compatibility, though, there's probably no reason to voluntarily take the burden of dealing with the things that are unsafe in C.

cvwright 10y ago
> Now, one approach is to make a struct buffer {char ptr; size_t len;}. A "fat" pointer. That's essentially what the Cello project does [1]. The author has pulled together some crazy hacks to make this approach accessible in C. Including, apparently his own version of many standard library routines. Crazy, but very interesting. Discussed on HN yesterday/today: https://news.ycombinator.com/item?id=14091630 https://news.ycombinator.com/item?id=14091630 [1] http://libcello.org/learn/a-fat-pointer-library http://libcello.org/learn/a-fat-pointer-library