Non-Transparent Memory Safety | Hacker News Reader

Non-Transparent Memory Safety

blog.regehr.org

70 pointsluu8 comments

  int lookup (int *COUNT(array.length) array, int index) {
    return array[index];
  }

Shouldn't there be an assert(index < array.length) in there too? Looks a bit half baked to me otherwise.

The links from the paper are broken, and the above regehr.org page makes references to Internet Wayback Machine archives.

Where has the Deputy material gone?

tl,dr: runtime array bound checking which assumes explicit annotations are correct, which is to say this dialect can't relieve you of the need for unattainable perfection from everyone who ever touched the code, and humans writing C is still a terrible mistake.

Wrong, incorrect Deputy annotations (other than the UNSAFE annotation) cannot lead to memory safety violations. I edited to post a bit to make this more clear.

Consider

http://msdn.microsoft.com/en-us/library/windows/desktop/ms63...

where the window system makes a callback including a pointer lpCreateParams whose type depends on what you did earlier while creating a window. Deputy can't possibly know whether you're using that pointer in a typesafe way, it just has to believe every TRUSTED cast you make, any of which could be wrong (and some surely will).

If you want to say that's bad API design, I wouldn't argue, but I found that kind of thing to be normal in C, and the massive reinvestment in getting rid of all code like that might as well include switching to a language that doesn't create these problems.

We found that UNSAFE/TRUSTED code wasn't needed very often. YMMV.

So don't bother trying to make it better because it can never be perfect?

There are multiple orders of magnitude difference in the effort needed to completely rewrite an entire API implementation in this other language vs. adding some annotations to the existing code. Sure it can't catch some really dirty type abuse like that, but it would let you identify when it is happening so you can prioritize your focus accordingly.

I'm not saying this shouldn't exist or that anyone shouldn't use it. If you're using C for some reason, your system is riddled with flaws, all of which are catastrophic, and you should use every tool you can find to eliminate them. But you should also be aware it's not going to help very much unless you can throw away all legacy code.

Reply on news.ycombinator.com