Ask HN: Why is there not a memory-safe C?

A lot of Rust complexity exists to allow memory manipulation while ensuring safety without requiring garbage collection. Take something simple like taking the address of an object on the stack. In C, you get a pointer that becomes invalid when the function returns; subsequent access to that pointer will access garbage, or the local variables of another function activation. In Go, the local value is promoted to the heap; you can continue using the pointer once the function has returned, but you need a GC to clean it up. In Rust, you have memory safety and don't need a GC. But you get a pointer qualified to a region such that it can't escape the scope of the enclosing function. The whole machinery of regions (and corresponding syntactic complexity) arises out of the need to achieve memory safety without GC.

Why is C not memory safe? It's because you can create things and forget to destroy them, destroy things that are already destroyed, or trust an inaccurate wrray length.

If you never do anything of those your program is anecdotally memory safe. Turn all things into libraries (strings, basic data structures, etc) and verify those closely and your C is now what many people call "memory safe". Add valgrind on that and you're pretty safe.

Good patterns and good tooling can combat any issues you have with C if you need to use C. Otherwise just use one of the "!C" languages out there

Other good things:

    - Every warning is an error until you can explain to me why that code can't be rewritten any other way

    - All code is compiled with -pedantic 

    - preprocessor hacks should be replaced with inline static functions 

    - const everywhere

D programming language has a memory safe subset called safe-d (https://dlang.org/articles/safed.html) and a subset called better c (https://dlang.org/spec/betterc.html) so you can probably use a combination of two subsets

There's also Cyclone which tried to be safer than C in some respects. It was used by a DoD Linux distro called AUXillery OS iirc. Mysteriously disappeared from the internet a few years back. They were making sure every bit of the kernel was safe. I think its goals was for jet planes or something mission critical enough. Kept looking back every few years on Wikipedia till the page disappeared and the homepage.

Edit: Wow now I absolutely cannot find a darn thing about that distro. Used to be one last page detailing the project left. It was quite interesting, wish they hadn't shut down the homepage at least.

Edit 2: Looks like it was called AuroraUX here's a bit more info on it:

https://www.openhub.net/p/AuroraUX https://www.phoronix.com/scan.php?page=news_item&px=MTIyMTI

Even found a blog post from someone who was apparently developing AuroraUX:

http://ultravioletos.blogspot.com/2009/09/opensolaris-distro...

Gotta love mysterious little Operating Systems. Looks like they were being maintained by Blastwave which was some sort of OpenSolaris focused company.

Found a Spanish wikipedia entry still alive which mentions support for Cyclone:

https://es.wikipedia.org/wiki/AuroraUX

(Google Translate if you don't know Spanish :)

I'd say that this is Rust. Ensuring at compile time that references are handled in a memory safe manner (borrow checking) requires a certain amount of complexity. There are of course plenty of memory safe languages more syntactically and semantically similar to C which just use a garbage collector. D and Go for instance.

I think unfortunately that the way C handles memory is so ingrained in the language and the standard library that to have a safe version of C would be a different enough language to have to call it a different name.

There is Safe-C[0], but it's not directly compilable as C and vice versa, and there are libraries like Cello[1] which provide higher level mechanisms like garbage collection to C.

[0] http://www.safe-c.org/ [1] http://libcello.org/

Yeah, there is. It is called Go.

Well, while my answer is not meant to be serious, Go started as "C with some improvements", and the three person team who first wrote it had among them Ken Thompson, one of the first users of C. Because it is garbage collected, it mostly abstracts away the memory allocation from the programmer. There's penalty in performance, though. It's a trade-off that allows the programmer to not think much about it. Go favors simplicity over speed while Rust tries to have speed as a main goal, and sometimes the tradeoff is more complexity.

If you started on the project of making such a language, you would have to make choices about how to adapt dynamic memory allocation, pointer assignment and arithmetic, the various ways in which functions can return pointers to out-of-scope variables, the way C decays arrays to pointers when passing them to functions, and the way C accommodates separate compilation. Most of these issues touch the core paradigms of C, and if you were to build a decision tree of all the options, you would find that none of the leaves would be a subset of C. You would probably also find that each leaf is already well-served by an existing language.

Take a look at Cyclone:

https://en.wikipedia.org/wiki/Cyclone_(programming_language)

https://cyclone.thelanguage.org/

http://wiki.c2.com/?CycloneLanguage

Rust should be compared to c++, not C.

Your question still stands. However, it's not too hard to be "memory safe" in modern c++.

Yes, there is a less powerful subset of C that is memory safe.

You can use local variables, but no pointer types - no variables with pointer types, no functions that return a pointer type, and don't use the * or & operations which dereference or create a pointer.

Initialize everything - there are compiler warnings to help with that.

Admittedly, this subset of C isn't particularly useful. No dynamic memory, no strings or file i/o since those functions from the standard library take pointers. You could definitely do some arithmetic and return the value from main() in a completely memory-safe manner using this subset, though.

There have been a few attempts to make C safer. However, one of the most popular aspects of C is the fact that it works everywhere. That means vendors are expected to have a working compiler for their platform. The easiest way to do that is to keep C features minimal. C99 was controversial because it asked these vendors to comply with changes in the language. C11 actually reduced many of the requirements in C99, making them optional. Sometimes this can be frustrating for programmers. Luckily clang-tidy and various sanitizers or valgrind can catch many issues you will encounter writing C.

It would have to be so radically different that it wouldn't resemble C. All sorts of standard C idiom is inherently unsafe, like zero terminated strings and pointer arithmetic.

There is. The D programming language https://www.dlang.org

You need to be more specific about what you are looking for: user-choice safety (i.e., a convenient way or a library for users to do most of the things that C does in a memory safe fashion, which is not enforced by the language / compiler), enforced safety or something else. Depending on this choice the arguments and benefits for it might be different.

That said, IME new C projects (not maintaining old monsters, for which a new language or library will not help) are mainly small components or libraries where you need to be close to hardware. In those cases, it might be better to reap benefits of being simple, clean and close to problem domain (hardware) and mitigate dangers by keeping the C code small, modular and clean.

Not criticizing, just asking an honest counter-question: what for (use cases)?

The main value of C is being the most compatible, well-known lowest common denominator. As soon as you add anything to it, it's no longer the C language, and you lose the benefit of universal compatibility and acceptance. This creates network effect in the C ecosystem that is so strong, that C99 is still "new", and C11 is an experimental curiosity.

Anyone trying to improve C has to face the dilemma that being "C but better" doesn't seem to offer enough for C users to switch (you get all the headache of a "new" language for one or two features), and languages adding enough improvements to justify cost of switching have to evolve to the point of no longer looking like C.

There are quite a few as research projects. They've just never hit the mainstream. Or gotten out of the lab at all.

If I can nitpick your last sentence for a second, that's the wrong way to think about it. The parts of C that are dangerous aren't the "powerful" parts; in particular, whether your can write a distributed system is beside the point. The dangerous parts of C include basics like arrays that you need for every program. Fixing them won't affect your ability to do almost anything.

There is also a language called zig[1], which popped up on hckrnews a few times in the past. I didn't have the chance to try it out, but am following the blog.

From what I can gather, it supports compile time code execution and reflection, so no preprocessor necessary. Furthermore it has a lot of safety features and optional checks, a nullable type instead of null value and manual memory management but also provides a `defer` statement.

[1] https://ziglang.org

> Could there be a less powerful subset of C

You probably meant minimal superset of C (as C doesn't have nontrivial or similarly performant memory-safe subset). And probably, although its niche would be smaller. Either you have complexity in language or in code. Systems software is more often larger and more complex so it less often makes sense to choose language that's easier to learn that is then harder to write in.

That reminds me ADA selling points about 20 years ago: Type safe, concurrency, and easy to read syntax.

Of course ADA didn't made it outside military contractors.

Anyone dos know why?

Have a look at C2: http://c2lang.org/site/

The question and all answers so far assume that memory safety is a clear and well-understood concept!

Au contraire!

Can I bring [1] to your attention? The paper argues that our intuition about memory safety means allowing for local reasoning about state.

[1] https://arxiv.org/abs/1705.07354

C was always intended as a higher-level assembly, so by definition, it can't be memory-safe.

It needs to be revised and is not cool(tm) project than creating new language and rethinking how to avoid any pointer arithmetic (starting from char *str, to arrays char str[999]) is not very easy task.

https://en.wikipedia.org/wiki/MISRA_C is what you are looking for

https://github.com/Microsoft/checkedc

Worse is better. Process isolation, valgrind and similar tools are good enough.

D is better than rust IMHO.

There are at least a few memory safe C compilers (PoCs) [1] [2] [3] and probably more than a few memory safe C subsets [4] and dialects.

However, they are not part of the C ecosystem, they don't compile into C and don't provide anything like musl gcc wrapper to be able to incrementally add memory safety in certain situations.

[1] https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/

[2] http://sva.cs.illinois.edu/index.html

[3] http://chrisseaton.com/plas15/safec.pdf

[4] bounds checking feature in tcc https://bellard.org/tcc/ http://download.savannah.nongnu.org/releases/tinycc/

What is the use case for a “safe C”? You use C because you do want control over how your data is actually stored in memory, for reasons of efficiency, or performance, or dealing with hardware, or whatever reason. The ability to just grab a bunch of bytes and cast them to a struct is absolutely key in many real systems.

But if you really do want it, C offers the opportunity to replace malloc() with whatever you like... or to not malloc at all...

For the same reason there is no memory safe assembly language.

You could use smart pointers in c++11