4 ms·

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.

by regehr 12y ago

prodigal_erik 12y ago
Consider http://msdn.microsoft.com/en-us/library/windows/desktop/ms632603(v=vs.85).aspx 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.
- regehr 12y ago
  We found that UNSAFE/TRUSTED code wasn't needed very often. YMMV.
- Deregibus 12y ago
  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.
  - prodigal_erik 12y ago
    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.

4 ms·

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.

by regehr 12y ago

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.

prodigal_erik 12y ago
Consider http://msdn.microsoft.com/en-us/library/windows/desktop/ms632603(v=vs.85).aspx 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.
- regehr 12y ago
  We found that UNSAFE/TRUSTED code wasn't needed very often. YMMV.
- Deregibus 12y ago
  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.
  - prodigal_erik 12y ago
    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.