microsoft.com discussion: https://news.ycombinator.com/item?id=11900009

the obvious question: how does this compare to rust? it looks like rust and this aim to solve a very similar set of issues in more or less similar way ('static and dynamic checking'). i'd be very interested in a table that compares capabilities of both. of course there's a gigantic advantage of this being C, so in theory valid checked C would be valid C with all benefits of that.

Well, this isn't C: it's a different language that extends C. There's a big difference between that and just being C. In particular, valid checked C is not valid C, because checking requires using the language extensions.

Regarding the comparison to Rust, Rust prevents use-after-free, while this doesn't seem to from a skim of the paper. Use after free is one of the most, if not the most, common remote code execution security issues in C and C++ code nowadays.

Use after free is one of the most, if not the most, common remote code execution security issues in C and C++ code nowadays.

I'd love to see a citation on this. My gut feeling tells me buffer overruns and integer overflows are seriously in the running.

It is certainly "one of the most", even if it is not "the most".

I'd love to see a citation on this, as I asked for previously. Repeating the comment I replied to isn't a citation.

That is somewhere around asking for a citation if the sky is sometimes cloudy.

https://web.nvd.nist.gov/view/vuln/search-results?query=use-...

Before getting too excited and claiming that it's only 1.3% of all CVEs or something, remember that it's 1.3% of all vulnerabilities. (Especially with the explosion of dynamic web languages, a lot of CVEs aren't really C/C++-related.) There's a power law to these things, so by the power law metric, it's not that far behind "buffer overflow" (6,500 entries), and ahead of the well-known "format string" (577), which is also certainly "one of" the most common C issues.

Every single Pwn2Own vulnerability this year was UAF.

I don't believe pwn2own is representative of the security landscape in general.

Is that the only information you based your comment on?

I don't believe pwn2own is representative of the security landscape in general.

It's representative of the state of the art in attacking large, mature, modern C++ codebases.

Is that the only information you based your comment on?

No, it's due to watching lots of security bugs go by over the last several years. I work in this space, you know.

This seems to be a successor to CCured from 2005, a project partially funded by Microsoft. [1]

The general idea is straightforward: "The unchecked C pointer type * is kept and three new checked pointer types are added: one for pointers that are never used in pointer arithmetic and do not need bounds checking (ptr), one for array pointer types that are involved in pointer arithmetic and need bounds checking (array ptr), and one for pointer types that carry their bounds with them dynamically (span)." So this is really a new language derived from C, to which programs can be converted.

This is basically a good idea, but it's only useful if pushed hard by somebody like Microsoft. People won't convert without heavy pressure.

[1] https://www.cs.virginia.edu/~weimer/p/p477-necula.pdf

I thought so too, but looking at their paper, they have an impressive survey of prior approaches, and they explain their differences from CCured quite well. CCured used fat pointers, and apparently modified the data pointed to by WILD pointers (something I didn't know).

This seems interesting to me. I liked the way CCured did inference to document how you used and abused your pointers, but what it did with that information was maybe not ideal.

A link to the paper you are mentioning would be helpful.

Being pushed by Microsoft could be exactly the reason not to convert, for many people. Especially when there is no shortage of alternatives that are backed by a bit more benevolent entities (Rust, and many other less known variants).

To put things in perspective, consider than from web browsers and languages, to their respective ill-fated mobile OS efforts, nothing Mozilla created has ever gotten more adoption than something MS created.

Only if we don't count Netscape and JavaScript. They put it in the browser, for better or for worse.

According to w3counter ff and ie are neck to neck.

https://www.w3counter.com/globalstats.php

Last month ff was ahead

It depends on the country. In Germany Firefox is actually the most popular browser according to usage statistics (even ahead of Chrome).

Source: http://de.statista.com/statistik/daten/studie/13007/umfrage/... (German statistics office. Paywalled sadly, but you can see the first paragraph that describes Firefox market share at 52%.)

In reply to myself: The times are changing indeed. It seams that HN-ers started liking Microsoft. Whenever I post some concern, even if only mild, there is first a few upvotes, and then a bunch of downvotes.

Microsoft became the darling of the community, OR, in addition to embracing open source, they embraced voting ring tactics. These are two explanations I have, maybe there is another. Maybe my criticism really was obnoxious...

Maybe it's just because yes, we all remember the 90s. But today is not necessarily the 90s. It was a lot more recent that Google was a relatively benevolent company, and we've all seen how that's changed.

And the thing about open source projects, is just that. They're open source. If the wider community takes hold of them, there's not much Microsoft can do. Because then you just see a fork.

You don't have to be a fan of Microsoft to simply appreciate the contribution to open software, as it is.

The only catch in that perspective is that the language specification is open source, while Microsoft's compiler implementation is not.

So, yes, we can edit those TeX documents they put on GitHub to our heart's delight.

pff.. they are "open source" just because they want to attract developers, because without developers writing apps for their platform, Microsoft will die (as any other platform). They are still just money-makers and nothing else, there is no any idea except money behind their movements to Open Source world, otherwise they wouldn't take revenues from Android.

Everything you say may (probably is) true.

Now why does anything in your post matter?

Because it's important to distinct intention to contribute to open-source world and intention to use this world to make money.

It's sad to see that despite open source (or free/libre..etc) software being around for so long, people still don't get it that money and freedom are not mutually exclusive. I would argue that contributing to open source for business reasons is perhaps even more beneficial for the software and community than just doing it for a hobby or some philosophy because companies pay people to even work on stuff that is not exciting / interesting.

As if these were orthogonal. My employer encourages me to contribute to open-source precisely because the open-source tools are the best for the job and thus allow us to make more money.

last time I checked Microsoft was a company (not a platform) and like any other it has to make money to survive. Your saying is applicable to every other company releasing open source code

Approaches of Mozilla and Microsoft are quite different.

Yes they are... And believe it or not people / companies can change. And changing to a more open culture even if the reasons for doing this is because they will cease being competitive if they don't is still a good thing. Open source these days not only makes sense technically and ethically but also economically... And that's a good thing.

Did you think they would suddenly start waving "information wants to be free" flags?

Did I give any reason to think so?

Forced updates for Windows 10 burned all the credibility Microsoft was slowly regaining. Whatever might be going on in there, they still have enough of the old strongarm bullying monopolist in their collective corporate character that their good works really cannot be trusted over the long term.

What about forced updates makes them bullies? Or are you just generally angry?

I'm angry about the idea that forced updates might become a normal practice, because that could lead to a situation where it's difficult to find much software I am willing to use.

"Power to the people" has always been the whole point of personal computing, as far as I'm concerned. Give people control over their data, their processes, their lives; that's why we're doing this, isn't it?

That's why I'm doing it, at least.

My Android has forced updates. I have to put my phone in airplane mode before each reboot and kill the process to prevent it. Chrome has forced updates. A lot of things have forced updates these days, and nobody bats an eye about it. Microsoft does it, everyone loses their minds.

And 'forced' is a stretch anyways, how to block it is well documented, and was months in advance. And you can revert, something Google and others will not let you do.

- Security update != version update.

- Paid OS != Free OS.

- OS update != software update.

I have an Android 4.4 phone, Verizon/Google is trying to force my phone to install Android 5.1, a full version update to a version widely regarded as a lemon.

I paid for my phone. I paid for my Windows license. I paid a lot more for my phone, which Android is trying to forcibly update without my consent to a version which will cripple my phone's functionality substantially.

It seams that HN-ers started liking Microsoft.

Or maybe we stopped categorically demonizing some technology because of its provenience and started evaluating it based on criteria like usefulness and applicability.

You know, like if we actually take the "engineer" part of "software engineer" seriously instead of using it for everyone who once wrote a PHP page for his uncle.

it's funny how you are demonizing PHP in your comment

I don't think this project is an instance where this is an important aspect, but in general I do agree that some caution is warranted when using an open source project backed by a corporation (Microsoft or anyone else) in your code. As someone who was recently burned by what happened to RoboVM[1], I am now always careful to check for any CLAs that are required to contribute to open source projects before I decide to use them in anything important.

The fact than you can fork is nice, but if the project is too reliant on the paid staff and doesn't have enough community surrounding it to survive getting dropped by its benefactor, you better hope you have the resources to maintain it yourself. This can happen even with no ill-intention involved, but the whole RoboVM debacle has convinced me that Embrace, Extend, Extinguish is not quite dead at Microsoft.

[1]: https://news.ycombinator.com/item?id=11503808

How many startups have been killed by other corporations, including Google, FB and friends?

The RoboVM situation, while unfortunate is a lesson for people not to rely on proprietary tooling for portable projects.

While I mostly code on JVM and .NET languages during the day, I use C++ for my hobby projects on mobile OSes.

The reason being that C++ is an open standard and officially supported in all SDKs, no need for third party layers like RoboVM.

A few similar lessons with my time spent on programming languages that weren't first party on platform SDKs, made me always choose first party languages, if I have decision power in the selection process.

If that's all, it's nothing that cannot be done in-language with smart pointer/iterator types in C++.

but I don't want to move my embedded C projects to C++. If I can use a language extension to get some extra confidence in my programs without changing the language im using then that's a compelling proposition.

but here in the case of Microsoft Checked C , you still need to modify your actual source code to get safer one.

But you're moving to a safer subset, not a safer superset, so it still shouldn't require significant alterations.

Uhhh moving from set to subset is what requires alterations, set to superset does not, by definition.

The problem here is compiler support and performance.

C++ is an altered and extended form of C, thus I would say it is more accurate to call it a superset, rather than a subset. I'm not using precise definitions here.

And of course, but those will come in time. The point of it is that C++ isn't any safer (And actually, I would say is more risky in some aspects, because of the differences between (For example) the UB in C and C++), while Checked C is guaranteed to be safer, to a certain degree.

The difference between a language extension, and a new language, is one of degree, not kind. Personally, since the semantics of this "extension" go to the core of what one does in C, I consider Checked C a new language.

I agree, in principle. But reading over this document, the changes can be made in an incremental fashion. And with far less impact than switching to using C++ just for these (assuming equivalents exist) features.

switching to c++ can also be done in an incremental fashion.

Yes, but not quite as trivially as:

  Enable extension
  Add `checked` to array declarations. (for the simplest
  case they've implemented).

Converting to C++ also means making sure you have `extern "C"` in your function declarations to get around C++'s name mangling when calling C libraries. Among other, potential, source level changes. Or, similarly, making sure your C (now C++) library can be called correctly by C projects that depended on it.

I'm not sold on this project as we haven't seen any results of course, but the approach is simpler than switching to C++.

Reminds me of Cyclone: https://cyclone.thelanguage.org/

Many Cyclone ideas made it into Rust.

I strongly prefer Rust.

You should look at their paper. They have an impressive survey of prior approaches including Cyclone, and they claim that their approach (if I understand them correctly) could allow you to do some things outside of unsafe blocks if implemented in C# or Rust.

Interesting. I thought Microsoft has stopped liking C a while back. Remember complaining about C99 support in VS and getting a response about "Just use C++ compiler as a C compiler, you don't need C anymore". It took them until VS 2015 finally to support it.

Also the DDK (Windows Driver Development Kit) didn't support C++ in any meaningful way. If I remember correctly, all my drivers had to be written in C89.

This clarifies the need for a more "rust-like" C. I hope something like this will flow into standard C...

I wouldn't bet on it. Every safety feature added to the standard since C99 has been quietly dropped by compiler maintainers.

People could write safe code in the 70's. The point of C was to write high level (kinda portable) assembly. Not safety.

Every safety feature added to the standard since C99 has been quietly dropped by compiler maintainers.

Can you give one example of this, please?

Bounds checking interfaces in C99

Support:

GCC: Nope, why? Performance concerns

MSVC: Nope, why? Performance concerns

Clang/LLVM: Nope, why? Performance concerns. [1]

[1] LLVM has the op-codes to implement this, but Clang won't emit those op-codes with the c99 switch triggered.

I can't upvote this enough. I started to play with Rust a few months ago and I especially like their compile-time checks of the code. I don't see why C compiler vendors can't do the same thing. Imagine if folks like GreenHills or WindRiver adopt such a practice in their compiler. It would revolutionise their industry. IAR has MISRA-C checks in their compilers but that is not enough.

Because the C language is fundamentally hostile to Rust's safety features.

There's already an industry providing static analyzers for C (Coverity, Klocwork, Polyspace, etc). If you're doing mission-critical C you're probably using these already.

I wish they supported namespaces.

I've written lots of C and never had problems with buffer overruns, bounds checking, double frees, and other memory issues. Typically at a glance in one's code, I can tell when behavior may be undefined, and once someone has a little experience, they can avoid undefined behavior altogether. Why does so much work go into fixing these problems? In other words, what are some examples of use cases of a stricter language like this, that would be too complicated for human eyes to quickly verify?

Here you don't check the return value of calloc():

https://github.com/AndrewBelt/bored/blob/master/src/map.c#L3...

and then access it:

https://github.com/AndrewBelt/bored/blob/master/src/map.c#L4...

Here if realloc() fails, you'll have a memory leak and, again, accessing NULL later:

https://github.com/AndrewBelt/bored/blob/master/src/priq.c#L...

There is also integer overflow: alloc is int, so if it becomes greater than 2^31-1, it may wrap around [I think signed int behaviour in C is undefined in this case], and you'll allocate fewer bytes than needed, leading to buffer overflow.

So they couldn't be bothered to contribute that directly back to LLVM/Clang or am I missing something?

You know, some people seem to scoff at replacement Cs. I'm kind of one of them. I know my reason(s) though. It's not about other languages as much as C itself. I've been with it for awful long time now and I used to think I kind of know my way around it. I've changed that line of thinking, because I know it's not true. I make a lot of mistakes, especially considering memory. At least (almost all of) my code isn't public-facing.

Since I thought I knew C very well, I came to realisation (due to many memory bugs/leaks) that maybe that's not the case after all. What is it then? I can get performance out of it, lots of it (that's one thing I know to do, somewhat at least). That's when I questioned myself and started thinking that it's not that I know C (I don't, after 20 years or so), but that I am very comfortable with it and I don't want to change that comfort. C++ and 90's traumas and post 90's (STL) traumas had a lot to do with it. Now, I'm fishing out for newer languages that would replace C for me, Rust namely, but I'm still falling back to C all the time. Now, I'm thinking that that's just the way it is. I'm a C programmer and that's how it will stay. At least for a long while. I do and have used a lot (A LOT) of languages in my past, but my core is always C (also first language I've learned). I don't program anymore for a living (I do "creative stuff" in film and tv now), so that is now more prominent than any other time in the past. I do stuff for me only and I can pick and choose whatever I want to - yet, it's always C.

Sorry for the "rant".

All of the things which the C-like replacements for C are competely missing the point. All their goals can be achieved by using a decent high level language (not "C like"), together with using C for just those parts that have to run fast, or interact with the hardware.

"Let's make an improved C, and then write millions of codes in nothing but that" is a myopic non-starter.

How does this apply towards library creation, where the code is meant to be consumed by other programs languages?

While the total lines of code in libraries is less than that in applications, I would say the relative importance is more. That zlib has a fast and correct implementation matters to a lot of people.

That's right; one fast and correct zlib matters more than giving everyone an improved C so that they can all try to roll their own zlib that is fast and correct.

This mirrors my experience. C is a drug man. It's bad but you can't stop. You know how to get shit done in C and it's easy to think in. C is, IMO, something of a local optima for programming. Problem is, it's actually a relatively awful language, and I don't subscribe to the worse-is-better philosophy (though C may well be the best example of it).

Thankfully Rust gets my ML instincts going. I'm trying to use it more. It'll be nice not to be anxiously running my test suite under ASAN after every build.

Yeah but after sixty years of C, why should we trust an origanization like Mozilla? They've been thoroughly unwilling to come up with any sort of ANSI standard or anything, despite Rust being a reasonably mature language.

Google sought ECMA standardization when they took on Dart. Go language has an official specification, so someone could hypothetically re-implement it if they wanted to, and remain compatible Go projects.

Mozilla only wants Mozilla to be involved with Rust. They want everybody to use it in their systems, and have no input on where the language should go.

I had a go at this problem, backwards-compatible safe C, back in 2012.[1] It was discussed on the C standards mailing list, and the consensus was that it would work technically, but was politically infeasible. What I proposed was not too far from "Checked C", but the syntax was different.

I'd defined a "strict mode" for C. The first step was to add C++ references to C. The second step was to make arrays first-class objects, instead of reducing them to pointers on every function call. When passing arrays around, you'd usually use references to arrays, which wouldn't lose the size information as reduction to a pointer does.

Array size information for array function parameters was required, but could be computed from other parameters. For example, UNIX/Linux "read" is usually defined as

    int read(int fd, char buf[], size_t len);

The safe version would be

    int read(int fd, &char buf[len], size_t len);

In both cases, all that's passed at run time is a pointer, but the compiler now knows that the size of the array is "len" and has something to check it against. The check can be made at both call and entry, and in many cases, can be optimized out. In general, in all the places in C where you'd describe an array with a pointer with empty brackets, as with "buf[]", you'd now have to put in a size expression.

You could do pointer arithmetic, but only if the pointer had been initialized from an array, and was attached to that array for the life of the pointer.

    char s[100];
    char* p = s;
    ...
    char ch = *p++;

Because p is associated only with s, the compiler knows what to check it against.

There was more, but that's the general idea. A key point was that the run-time representation didn't change; there were no "fat pointers". Thus, you could intermix strict and non-strict compilation units, and gradually convert a working program to strict mode.

This took less new syntax and fewer new keywords than "Checked C". I was trying to keep C style, adding just enough that you could talk about arrays properly in C.

[1] http://www.animats.com/papers/languages/safearraysforc43.pdf

Perl introduced a "strict" mode a long time ago. Although it doesn't force it on you, virtually all modern Perl programmers use it by default.

As an extra security feature Perl also supports "taint" mode, which "taints" all user-supplied data as potentially hazardous to the program. This was used more for CGI, but it's still a simple and powerful security feature. Unfortunately, it was never adopted like 'use strict' was because it would more often get in the way of the programmer.

"strict mode" is an assistance to migration.

The fundamental memory safety problem in C is that arrays are not first-class objects. They degrade to pointers when passed around. Yet any function which references an array has to know how big it is. Somehow. The language has no syntax for this. That's the big problem, and what I was addressing.

I've already been downvoted for this question, but I don't get the business case here. If you are worried about this, why not write code in modern C++ which has plenty of ways to make all sorts of issues like this safe ? Why stick to C at all?

C++ doesn't solve the problem. C++ papers over the problem with templates. You can still get raw pointers out of C++ objects, and for most APIs, you have to. The underlying language objects are still unsafe.

ok, so write C++ classes that don't let you access raw pointers. I mean I understand that C/C++ languages are less safe than, say, Java - but that is the whole point. The lesser safety gives you better performance. If you don't care about bleeding edge performance, you should probably choose Java or Python or some other language that is much more flexible and easier to use