11 ms·

The Safe C Library (2009)

94 points by cvwright 10y ago

AnimalMuppet 10y ago
(2009)
- Safety1stClyde 10y ago
  The library itself seems to have been updated as recently as November 2016.
dguido 10y ago
The CheckedC compiler from Microsoft (built on LLVM) is probably a more complete solution to the issue of memory unsafety in C. Check it out! https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc
LambdaComplex 10y ago
C is not a safe language. This sort of thing seems (to me, at least) like a jury-rigged workaround rather than an actual solution. If you actually care about memory safety—which you should, as the CVE list shows—then why not use an actual memory-safe language?
- cyphar 10y ago
  Because every platform generally has a C compiler (which is usually GCC, not LLVM/clang).
  - c8g 10y ago
    even my tp link router has gcc!
- snickerbockers 10y ago
  There are no unsafe languages, only unsafe coders.
  - Someone 10y ago
    There are no unsafe cars, either, only unsafe drivers. However, there also are plenty of cars that safe drivers will refuse to drive. You don't need crumple zones, safety belts, etc. in a car you will never drive.
  - metajack 10y ago
    There are only unsafe coders.
  - Jweb_Guru 10y ago
    I'm going to go ahead and say that if (1) deciding whether code is valid for your language is undecidable, (2) no industrial compiler makes any effort to conservatively accept only valid programs, and (3) unsoundness cannot even be detected at runtime (this is true of C in the multithreaded case) and may result in completely arbitrary behavior, your language is unsafe.
  - geofft 10y ago
    I enjoy using computers because they make fewer mistakes than humans. I would like to apply the same principle to the language I program computers in. Make it the computer's job to minimize mistakes - it might not be perfect, but it's definitely better than I am!
    - lacampbell 10y ago
      I agree with this sentiment. What I disagree with is the sentiment (which I'm not saying you expressed) of a silver bullet for it. IE if only our test coverage was complete, or our type system was sophisticated enough.
      - LambdaComplex 10y ago
        You're right, there's no silver bullet. But it seems like some people have the mindset of "Since everything is bad and (to some extent), there's no point in trying to improve."
  - 10y ago
- Safety1stClyde 10y ago
  > This sort of thing seems (to me, at least) like a jury-rigged workaround rather than an actual solution. Really? I had a look at the code and I would agree with the basic idea of eliminating errno and always using the return value. > If you actually care about memory safety—which you should, as the CVE list shows—then why not use an actual memory-safe language? Following the logic here, you seem to be implying that no-one except the irresponsible should use C.
  - geofft 10y ago
    > Following the logic here, you seem to be implying that no-one except the irresponsible should use C. This seems highly likely, yes. C was a good language at the time. It's still probably a very good teaching language for systems programming. But it's a bad language for anyone who wants to write software that needs to be used responsibly. It predates the entire idea that some people on the network might be hostile. It predates the knowledge that buffer overflows might be used for malice. It predates about 40 years of programming language research and security research, some of which has even shown results. C also predates computers of modern speed; it was written at a time when interpreted languages were mostly unthinkable for serious software. There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today, but it was presumably the best tool for the job at the time. It is no criticism of C to say that it has served us well but it is a bad choice for new software for clear and objective reasons.
    - Safety1stClyde 10y ago
      > There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today Someone called Kristaps Dzonsons wrote a manual page renderer and a cgi/fastcgi library in C quite recently.
    - pjmlp 10y ago
      ESPOL and a full OS written in it, Burroughs B5500 nowadays sold as Unisys MCP, predates C by about 10 years, having been released in 1961. There were already powerful computers than the PDP-11, with more saner languages.
- zik 10y ago
  I once wrote a C interpreter for scripting (picoc) which had memory safety. To my surprise I received a lot of complaints from people who wanted the more conventional memory unsafe semantics. I changed it to being memory unsafe and I've never had any requests to change it back. Perhaps there's a place in this world for both approaches?
  - marktangotango 10y ago
    That's really interesting. Is there any documentation around for memor safe version? I'd like to study your implementation!
  - mamcx 10y ago
    Or more probable you userbase was full of C developers, that can't imagine to be possible to code outside the C-mindset. Take in account how many can't even consider the possibility that a full OS can (and have be made before) safer, have GC, is NOT C, is NOT EVEN ALIKE C, etc. C, C++, Unix are the biggest roadblock in the progres of computing. Or more exactly, the users, that prefer patch-along and commit million of dollars in wasted effort than in build (or rediscover) better ways. This is alike climate change resistance. Why go solar, if carbon is better and well understood? Instead, push ahead and waste money fixing symptoms instead of causes. And "causes" is a word that here mean, C, C++, Unix, etc...
    - pmilot 10y ago
      That's an unfair judgement toward the C development community as a whole. There are legitimate use cases for C. If you're writing low-level, bare-metal programs then there is no other portable programming language that offers better semantics. C programmers often laud that language because they can easily reason what the output of the compiler will be. That is an extremely important and rare property for a portable programming language. But hey, don't listen to me, listen to an actual experienced C programmer: https://youtu.be/MShbP3OpASA?t=20m45s https://youtu.be/MShbP3OpASA?t=20m45s
      - naasking 10y ago
- durandal1 10y ago
  In how many "safe" languages can you write a complete shipping application without calling into libraries and/or kernels written in C?
  - geofft 10y ago
    Today? Zero, probably. Five years from now? Probably a number of them. You've been able to write in Go with no standard library for years. There's a project to avoid it in Rust. There are lots of active kernel development projects. Do you want your software to continue to be written in C with a kernel and standard library in safe languages? And why does it matter to you to avoid improving your code until it's possible to run on an all-safe stack? It is as if it is 1990, and you are asking, why should I license my code as free software? How much can I run on a free C library and a free kernel?
    - steveklabnik 10y ago
      You don't need a project to do it with Rust, you just need a !#[no_std] marker.
  - nickpsecurity 10y ago
    Is C being in at some point even relevant? There's plenty of safer languages thst can fo that. There's also containers, OS's, and embedded runtimes for some. The first, business mainframe was even programmed in an early one. It's even still on market although less desirable today. And C itself has automated toolimg available like SAFEcode that can make it safer with one team doing that for FreeBSD. So you can make the C safe or get rid of it. However much work you want to put in.
  - steveklabnik 10y ago
    You can do so with Rust, and there's a number of them, from toy POCs to much more serious projects.
  - thesuperbigfrog 10y ago
    It depends on what platform you are targeting, but as far as safe languages go, it is hard to beat Ada: https://en.wikipedia.org/wiki/Ada_(programming_language) https://en.wikipedia.org/wiki/Ada_(programming_language) Although Rust shows a lot of promise, Ada has a proven track record of use in safety critical applications such as avionics and railways.
- 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
  I don't disagree. > If you actually care about memory safety ... then why not use an actual memory-safe language? Many teams are stuck with established codebases that they can't afford to re-write entirely from scratch. I think the proposal in the article is an interesting point on a continuum of mitigations for C, spanning from the really weak and/or hacky (but cheap/easy) all the way up to safe systems languages like Rust and Ivory. Other points on this continuum include Cyclone [1], SAFECode [2], and the fat pointer approach in Cello [3]. [1] http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/ [2] http://safecode.cs.illinois.edu/index.html http://safecode.cs.illinois.edu/index.html [3] http://libcello.org/learn/a-fat-pointer-library http://libcello.org/learn/a-fat-pointer-library
  - duneroadrunner 10y ago
    And don't forget the llvm (and gcc) sanitizers[1] and SaferCPlusPlus[2] (essentially a memory safe subset of C++), which are more modern and have arguably better overall combinations of performance/safety/compatibility/practicality. Automatic translation (assistance) from native C to SaferCPlusPlus is being worked on. And if you'll permit me to gripe a little here - you might think it's a reasonable undertaking, until you start contemplating code like this: int **var1 = (int **)malloc(20); var1[2] = (int *)malloc(10); int *var2 = var1[2] + 4; var2--; free(var2 - 3); free(var1); :) [1] https://github.com/google/sanitizers https://github.com/google/sanitizers [2] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
  - sametmax 10y ago
    > Many teams are stuck with established codebases that they can't afford to re-write entirely from scratch. You don't have to. Most alternative can call compiled C libraries. Rust can.
    - AstralStorm 10y ago
      Converting a monolithic chunk of code into modules then rewriting it in another language takes a lot of effort with not too much to show for it.
- catnaroek 10y ago
  (0) Memory safety alone doesn't fix the downsides of lacking a formally defined semantics. You can turn most undefined behavior into trapped errors for the cheap price of a constant overhead factor, but that won't make writing correct programs any little bit easier. Your programs will just fail in more manageable ways. (1) Once you have a formally defined semantics, undefined behavior is no big deal, because you have the tools to prove its absence in whatever program you're writing.
- snakeanus 10y ago
  > C is not a safe language More like "most C implementations do not offer memory safety by default". This is unrelated to the language per se, it's like for example calling Scheme unsafe because an implementation could have set-cdr! on '() write on random memory. It can be applied to any language.
  - boomlinde 10y ago
    Is it C if it's incompatible with any standardized or widely accepted notion of it?
- GoToRO 10y ago
  Because they use a library to manage memory is one reason. Also they use linters which means that the C that they write is totally different from the C you see in tutorials. Of course it depends on the company/project.
- Nokinside 10y ago
  For new Language to become safe you need to write state of-the-art linters, static source code analyzers, dynamic code analyzers, code coverage analysis tools, testing tools for the language. C has all these. Only C/C++ and Ada have these. People who say "C is not a safe language" may not be aware, but most of the worlds safety critical code is written in C or ancient C++. Most aerospace, military and medical applications are written either in C/C++ or Ada. Ada would be much safer than C, but it has been abandoned for C/C++ because language of choice is not that important. If the culture and tooling to write safe code is not there, changing language is not going to help. It's currently easier to write safe code in C than it's to write safe code in your favorite 'memory safe' language like Rust. https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C
  - danieltillett 10y ago
    This is so true. It seems like most of the arguments against C are made in isolation of the ecosystem that has been built around C. At this point we should be helping new programmer learn how to work with C with all the safely equipment we now have.
    - pjmlp 10y ago
      Because only around 1% of all C developers care to use such band aids.
      - Nokinside 10y ago
        They are not band aids. Analysis tools for C exceed anything you can have in Rust or Go compiler in scope and features.
        danieltillett 10y ago
        Exactly. The real problem is many C developers are unaware of these tools. Rather than just saying use programming language x, we should be helping people use C with the right tools.
geofft 10y ago
This is a link to https://sourceforge.net/projects/safeclib/ https://sourceforge.net/projects/safeclib/ , an implementation of ISO/IEC TR 24731-1. In brief, TR24731-1 provides: - a type rsize_t, typedef'd to size_t, but by convention limited to a lower value RSIZE_MAX that is ideally no larger than SIZE_MAX/2, thereby preventing some classes of arithmetic overflows (adding two valid rsize_ts never overflows, but the next function using it will complain at runtime if it exceeds RSIZE_MAX) - a large number of functions ending in _s, like memcpy_s and tmpnam_s, which use rsize_t as their size type, take lengths with every buffer, and return an errno instead of a direct value Wikipedia says that TR24731-1 "has met severe criticism with some praise.... Despite this, TR 24731-1 has been implemented into Microsoft's C standard library and its compiler issues warnings when using old 'insecure' functions." glibc 2.25, released last month, has provisional support for it. Wikipedia links to this Austin Group report criticizing TR24731: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt The approach of simply providing a length argument to a number of string functions may cause as many problems as it solves. It provides no assurance that the programmer provide a sensible value, and may end up obfuscating otherwise clear and safe usage of the original function. Functions that allocate memory (using malloc()) would provide safer, clearer, and more robust interfaces. E.g. strdup() instead of strcpy(). and this Stack Overflow thread: https://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions https://stackoverflow.com/questions/372980/do-you-use-the-tr... On a side note, especially now that it's a decade or so after TR24731-1 was released, there are many good languages (some compiled, some interpreted, only one of which rhymes with "overdiscussed") that are suitable to a lot of the things you'd want to use C for a decade ago, and solve the problem in a straightforward way that resolves the objection above: they provide either buffer types that remember their own capacity, string objects capable of allocating as necessary, or both. There are also C libraries that do the same (bstring and GTK+ come to mind), if you're inclined to continue writing C.
- Gibbon1 10y ago
  > (using malloc()) would provide safer, clearer, and more robust interfaces. E.g. strdup() instead of strcpy(). malloc() ... Lutz
- rurban 10y ago
jaunkst 10y ago
Safety first, an opt out for control.
emmelaich 10y ago
(2009)
vkazanov 10y ago
Only 8 mentions of Rust per C/C++ related link. I am disappointed!
- vkazanov 10y ago
  14 now, including the one in my comment. That's more like it, but I think we can do even better.
joaodlf 10y ago
I'm saddened by some of the comments here. It's true that C is not safe. It's true you shouldn't be using it for large portions of your professional setting. It's true that these sort of libraries appear to be slapping a bandaid on a broken bone... All of those things are true, but you should learn C. And you should learn it well. I wonder where we will be in as little as 10, 20 years. When the C dinosaurs die and universities stop teaching the basics of computers. Young programmers are being pushed away from the harsh realities of C (not to mention anything below C), who's going to be building the building blocks in the future? Who's is going to keep optimising modern languages like Go and Rust? That minority is only going to get smaller...
- lmm 10y ago
  > All of those things are true, but you should learn C. And you should learn it well. No, you shouldn't, unless you're a historian. It's not just a waste of your time, there are enough bad design decisions that using it will actively make you a worse programmer. > Who's is going to keep optimising modern languages like Go and Rust? Talented Rust programmers. The language is perfectly well suited to self-hosting.
  - camgunz 10y ago
    I get what you're saying, but don't be so dismissive. There are a lot of industries that will probably never move off of C (aerospace, for one). Plus, C fluency is pretty much required for serious security work.
    - lmm 10y ago
      > There are a lot of industries that will probably never move off of C (aerospace, for one). A lot of aerospace is in Ada already isn't it? And the parts that do use C use such specialized subsets of it that general-purpose C knowledge isn't very valuable (e.g. you won't be able to use any of the libraries you're used to if you're working in aerospace). > Plus, C fluency is pretty much required for serious security work. Only a very niche subset of security work.
EternalFury 10y ago
There is no substitute for discipline. The unskilled always blame their tools. That is all.
gens 10y ago
In this whole thread, among all these talks about memory safety, zero mentions of valgrind.

94 points by cvwright 10y ago

AnimalMuppet 10y ago

(2009)

Safety1stClyde 10y ago
The library itself seems to have been updated as recently as November 2016.

dguido 10y ago

The CheckedC compiler from Microsoft (built on LLVM) is probably a more complete solution to the issue of memory unsafety in C. Check it out! https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc

LambdaComplex 10y ago

C is not a safe language. This sort of thing seems (to me, at least) like a jury-rigged workaround rather than an actual solution. If you actually care about memory safety—which you should, as the CVE list shows—then why not use an actual memory-safe language?

cyphar 10y ago
Because every platform generally has a C compiler (which is usually GCC, not LLVM/clang).
- c8g 10y ago
  even my tp link router has gcc!
snickerbockers 10y ago
There are no unsafe languages, only unsafe coders.
- Someone 10y ago
  There are no unsafe cars, either, only unsafe drivers. However, there also are plenty of cars that safe drivers will refuse to drive. You don't need crumple zones, safety belts, etc. in a car you will never drive.
- metajack 10y ago
  There are only unsafe coders.
- Jweb_Guru 10y ago
  I'm going to go ahead and say that if (1) deciding whether code is valid for your language is undecidable, (2) no industrial compiler makes any effort to conservatively accept only valid programs, and (3) unsoundness cannot even be detected at runtime (this is true of C in the multithreaded case) and may result in completely arbitrary behavior, your language is unsafe.
- geofft 10y ago
  I enjoy using computers because they make fewer mistakes than humans. I would like to apply the same principle to the language I program computers in. Make it the computer's job to minimize mistakes - it might not be perfect, but it's definitely better than I am!
  - lacampbell 10y ago
    I agree with this sentiment. What I disagree with is the sentiment (which I'm not saying you expressed) of a silver bullet for it. IE if only our test coverage was complete, or our type system was sophisticated enough.
    - LambdaComplex 10y ago
      You're right, there's no silver bullet. But it seems like some people have the mindset of "Since everything is bad and (to some extent), there's no point in trying to improve."
- 10y ago
Safety1stClyde 10y ago
> This sort of thing seems (to me, at least) like a jury-rigged workaround rather than an actual solution. Really? I had a look at the code and I would agree with the basic idea of eliminating errno and always using the return value. > If you actually care about memory safety—which you should, as the CVE list shows—then why not use an actual memory-safe language? Following the logic here, you seem to be implying that no-one except the irresponsible should use C.
- geofft 10y ago
  > Following the logic here, you seem to be implying that no-one except the irresponsible should use C. This seems highly likely, yes. C was a good language at the time. It's still probably a very good teaching language for systems programming. But it's a bad language for anyone who wants to write software that needs to be used responsibly. It predates the entire idea that some people on the network might be hostile. It predates the knowledge that buffer overflows might be used for malice. It predates about 40 years of programming language research and security research, some of which has even shown results. C also predates computers of modern speed; it was written at a time when interpreted languages were mostly unthinkable for serious software. There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today, but it was presumably the best tool for the job at the time. It is no criticism of C to say that it has served us well but it is a bad choice for new software for clear and objective reasons.
  - Safety1stClyde 10y ago
    > There's no reason that, say, the manpage rendering tools (the most recent thing I had half a mind of exposing to the network) would be written in C today Someone called Kristaps Dzonsons wrote a manual page renderer and a cgi/fastcgi library in C quite recently.
  - pjmlp 10y ago
    ESPOL and a full OS written in it, Burroughs B5500 nowadays sold as Unisys MCP, predates C by about 10 years, having been released in 1961. There were already powerful computers than the PDP-11, with more saner languages.
zik 10y ago
I once wrote a C interpreter for scripting (picoc) which had memory safety. To my surprise I received a lot of complaints from people who wanted the more conventional memory unsafe semantics. I changed it to being memory unsafe and I've never had any requests to change it back. Perhaps there's a place in this world for both approaches?
- marktangotango 10y ago
  That's really interesting. Is there any documentation around for memor safe version? I'd like to study your implementation!
- mamcx 10y ago
  Or more probable you userbase was full of C developers, that can't imagine to be possible to code outside the C-mindset. Take in account how many can't even consider the possibility that a full OS can (and have be made before) safer, have GC, is NOT C, is NOT EVEN ALIKE C, etc. C, C++, Unix are the biggest roadblock in the progres of computing. Or more exactly, the users, that prefer patch-along and commit million of dollars in wasted effort than in build (or rediscover) better ways. This is alike climate change resistance. Why go solar, if carbon is better and well understood? Instead, push ahead and waste money fixing symptoms instead of causes. And "causes" is a word that here mean, C, C++, Unix, etc...
  - pmilot 10y ago
    That's an unfair judgement toward the C development community as a whole. There are legitimate use cases for C. If you're writing low-level, bare-metal programs then there is no other portable programming language that offers better semantics. C programmers often laud that language because they can easily reason what the output of the compiler will be. That is an extremely important and rare property for a portable programming language. But hey, don't listen to me, listen to an actual experienced C programmer: https://youtu.be/MShbP3OpASA?t=20m45s https://youtu.be/MShbP3OpASA?t=20m45s
    - naasking 10y ago
durandal1 10y ago
In how many "safe" languages can you write a complete shipping application without calling into libraries and/or kernels written in C?
- geofft 10y ago
  Today? Zero, probably. Five years from now? Probably a number of them. You've been able to write in Go with no standard library for years. There's a project to avoid it in Rust. There are lots of active kernel development projects. Do you want your software to continue to be written in C with a kernel and standard library in safe languages? And why does it matter to you to avoid improving your code until it's possible to run on an all-safe stack? It is as if it is 1990, and you are asking, why should I license my code as free software? How much can I run on a free C library and a free kernel?
  - steveklabnik 10y ago
    You don't need a project to do it with Rust, you just need a !#[no_std] marker.
- nickpsecurity 10y ago
  Is C being in at some point even relevant? There's plenty of safer languages thst can fo that. There's also containers, OS's, and embedded runtimes for some. The first, business mainframe was even programmed in an early one. It's even still on market although less desirable today. And C itself has automated toolimg available like SAFEcode that can make it safer with one team doing that for FreeBSD. So you can make the C safe or get rid of it. However much work you want to put in.
- steveklabnik 10y ago
  You can do so with Rust, and there's a number of them, from toy POCs to much more serious projects.
- thesuperbigfrog 10y ago
  It depends on what platform you are targeting, but as far as safe languages go, it is hard to beat Ada: https://en.wikipedia.org/wiki/Ada_(programming_language) https://en.wikipedia.org/wiki/Ada_(programming_language) Although Rust shows a lot of promise, Ada has a proven track record of use in safety critical applications such as avionics and railways.
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
I don't disagree. > If you actually care about memory safety ... then why not use an actual memory-safe language? Many teams are stuck with established codebases that they can't afford to re-write entirely from scratch. I think the proposal in the article is an interesting point on a continuum of mitigations for C, spanning from the really weak and/or hacky (but cheap/easy) all the way up to safe systems languages like Rust and Ivory. Other points on this continuum include Cyclone [1], SAFECode [2], and the fat pointer approach in Cello [3]. [1] http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/ [2] http://safecode.cs.illinois.edu/index.html http://safecode.cs.illinois.edu/index.html [3] http://libcello.org/learn/a-fat-pointer-library http://libcello.org/learn/a-fat-pointer-library
- duneroadrunner 10y ago
  And don't forget the llvm (and gcc) sanitizers[1] and SaferCPlusPlus[2] (essentially a memory safe subset of C++), which are more modern and have arguably better overall combinations of performance/safety/compatibility/practicality. Automatic translation (assistance) from native C to SaferCPlusPlus is being worked on. And if you'll permit me to gripe a little here - you might think it's a reasonable undertaking, until you start contemplating code like this: int **var1 = (int **)malloc(20); var1[2] = (int *)malloc(10); int *var2 = var1[2] + 4; var2--; free(var2 - 3); free(var1); :) [1] https://github.com/google/sanitizers https://github.com/google/sanitizers [2] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
- sametmax 10y ago
  > Many teams are stuck with established codebases that they can't afford to re-write entirely from scratch. You don't have to. Most alternative can call compiled C libraries. Rust can.
  - AstralStorm 10y ago
    Converting a monolithic chunk of code into modules then rewriting it in another language takes a lot of effort with not too much to show for it.
catnaroek 10y ago
(0) Memory safety alone doesn't fix the downsides of lacking a formally defined semantics. You can turn most undefined behavior into trapped errors for the cheap price of a constant overhead factor, but that won't make writing correct programs any little bit easier. Your programs will just fail in more manageable ways. (1) Once you have a formally defined semantics, undefined behavior is no big deal, because you have the tools to prove its absence in whatever program you're writing.
snakeanus 10y ago
> C is not a safe language More like "most C implementations do not offer memory safety by default". This is unrelated to the language per se, it's like for example calling Scheme unsafe because an implementation could have set-cdr! on '() write on random memory. It can be applied to any language.
- boomlinde 10y ago
  Is it C if it's incompatible with any standardized or widely accepted notion of it?
GoToRO 10y ago
Because they use a library to manage memory is one reason. Also they use linters which means that the C that they write is totally different from the C you see in tutorials. Of course it depends on the company/project.
Nokinside 10y ago
For new Language to become safe you need to write state of-the-art linters, static source code analyzers, dynamic code analyzers, code coverage analysis tools, testing tools for the language. C has all these. Only C/C++ and Ada have these. People who say "C is not a safe language" may not be aware, but most of the worlds safety critical code is written in C or ancient C++. Most aerospace, military and medical applications are written either in C/C++ or Ada. Ada would be much safer than C, but it has been abandoned for C/C++ because language of choice is not that important. If the culture and tooling to write safe code is not there, changing language is not going to help. It's currently easier to write safe code in C than it's to write safe code in your favorite 'memory safe' language like Rust. https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C
- danieltillett 10y ago
  This is so true. It seems like most of the arguments against C are made in isolation of the ecosystem that has been built around C. At this point we should be helping new programmer learn how to work with C with all the safely equipment we now have.
  - pjmlp 10y ago
    Because only around 1% of all C developers care to use such band aids.
    - Nokinside 10y ago
      They are not band aids. Analysis tools for C exceed anything you can have in Rust or Go compiler in scope and features.
      - danieltillett 10y ago
        Exactly. The real problem is many C developers are unaware of these tools. Rather than just saying use programming language x, we should be helping people use C with the right tools.

geofft 10y ago

This is a link to https://sourceforge.net/projects/safeclib/ https://sourceforge.net/projects/safeclib/ , an implementation of ISO/IEC TR 24731-1. In brief, TR24731-1 provides: - a type rsize_t, typedef'd to size_t, but by convention limited to a lower value RSIZE_MAX that is ideally no larger than SIZE_MAX/2, thereby preventing some classes of arithmetic overflows (adding two valid rsize_ts never overflows, but the next function using it will complain at runtime if it exceeds RSIZE_MAX) - a large number of functions ending in _s, like memcpy_s and tmpnam_s, which use rsize_t as their size type, take lengths with every buffer, and return an errno instead of a direct value Wikipedia says that TR24731-1 "has met severe criticism with some praise.... Despite this, TR 24731-1 has been implemented into Microsoft's C standard library and its compiler issues warnings when using old 'insecure' functions." glibc 2.25, released last month, has provisional support for it. Wikipedia links to this Austin Group report criticizing TR24731: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt The approach of simply providing a length argument to a number of string functions may cause as many problems as it solves. It provides no assurance that the programmer provide a sensible value, and may end up obfuscating otherwise clear and safe usage of the original function. Functions that allocate memory (using malloc()) would provide safer, clearer, and more robust interfaces. E.g. strdup() instead of strcpy(). and this Stack Overflow thread: https://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions https://stackoverflow.com/questions/372980/do-you-use-the-tr... On a side note, especially now that it's a decade or so after TR24731-1 was released, there are many good languages (some compiled, some interpreted, only one of which rhymes with "overdiscussed") that are suitable to a lot of the things you'd want to use C for a decade ago, and solve the problem in a straightforward way that resolves the objection above: they provide either buffer types that remember their own capacity, string objects capable of allocating as necessary, or both. There are also C libraries that do the same (bstring and GTK+ come to mind), if you're inclined to continue writing C.

Gibbon1 10y ago
> (using malloc()) would provide safer, clearer, and more robust interfaces. E.g. strdup() instead of strcpy(). malloc() ... Lutz
rurban 10y ago

jaunkst 10y ago

Safety first, an opt out for control.

emmelaich 10y ago

(2009)

vkazanov 10y ago

Only 8 mentions of Rust per C/C++ related link. I am disappointed!

vkazanov 10y ago
14 now, including the one in my comment. That's more like it, but I think we can do even better.

joaodlf 10y ago

I'm saddened by some of the comments here. It's true that C is not safe. It's true you shouldn't be using it for large portions of your professional setting. It's true that these sort of libraries appear to be slapping a bandaid on a broken bone... All of those things are true, but you should learn C. And you should learn it well. I wonder where we will be in as little as 10, 20 years. When the C dinosaurs die and universities stop teaching the basics of computers. Young programmers are being pushed away from the harsh realities of C (not to mention anything below C), who's going to be building the building blocks in the future? Who's is going to keep optimising modern languages like Go and Rust? That minority is only going to get smaller...

lmm 10y ago
> All of those things are true, but you should learn C. And you should learn it well. No, you shouldn't, unless you're a historian. It's not just a waste of your time, there are enough bad design decisions that using it will actively make you a worse programmer. > Who's is going to keep optimising modern languages like Go and Rust? Talented Rust programmers. The language is perfectly well suited to self-hosting.
- camgunz 10y ago
  I get what you're saying, but don't be so dismissive. There are a lot of industries that will probably never move off of C (aerospace, for one). Plus, C fluency is pretty much required for serious security work.
  - lmm 10y ago
    > There are a lot of industries that will probably never move off of C (aerospace, for one). A lot of aerospace is in Ada already isn't it? And the parts that do use C use such specialized subsets of it that general-purpose C knowledge isn't very valuable (e.g. you won't be able to use any of the libraries you're used to if you're working in aerospace). > Plus, C fluency is pretty much required for serious security work. Only a very niche subset of security work.

EternalFury 10y ago

There is no substitute for discipline. The unskilled always blame their tools. That is all.

gens 10y ago

In this whole thread, among all these talks about memory safety, zero mentions of valgrind.