7 ms·

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 m

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."
- mamcx 10y ago
  >There are no unsafe languages, only unsafe coders. And who develop the languages? Coders. Ergo, exist unsafe languages.
- naasking 10y ago
  > There are no unsafe languages, only unsafe coders. There are no unsafe nuclear launch buttons, only unsafe nuclear launch button pushers. Hmm, maybe some buttons should be harder to push...
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.

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."
mamcx 10y ago
>There are no unsafe languages, only unsafe coders. And who develop the languages? Coders. Ergo, exist unsafe languages.
naasking 10y ago
> There are no unsafe languages, only unsafe coders. There are no unsafe nuclear launch buttons, only unsafe nuclear launch button pushers. Hmm, maybe some buttons should be harder to push...

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.