Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make Debug and ReleaseSafe modes fully safe #2301

Open
andrewrk opened this issue Apr 18, 2019 · 1 comment

Comments

Projects
None yet
1 participant
@andrewrk
Copy link
Member

commented Apr 18, 2019

It's always going to be possible to do unsafe things in Zig, because we have inline assembly, @intToPtr, and ability to call extern functions with the wrong ABI.

But what if we could eliminate everything else? What if, after enumerating all kinds of undefined behavior (See #1966), we could make all of them safety-checked, with only some obvious exceptions such as inline assembly?

  • even @intToPtr could look at the type it was casting to and make sure it is correct, somehow?
  • runtime safety for pointer lifetimes? can we solve use-after-free? This is the big one.
  • try to solve everything on the list turned up by #1966.

This might turn out to be impossible or impractical, but it's worth investigating.

If we could reduce the unchecked undefined behavior surface to a minimum level, there could be auditing/linting tools to point out where unsafety lies in zig software. It would be possible to say something like, "Debug and ReleaseSafe builds of Zig code are safe (in that they crash rather than have undefined behavior), except for inline assembly and extern function ABI mismatch", or some short list of exceptions.

If the cost of these protections is high, that's what we have @setRuntimeSafety for (see #978).

It would be reasonable for these protections to depend on OS-specific behavior, and to be unavailable on some targets, such as freestanding.

@andrewrk andrewrk added the proposal label Apr 18, 2019

@andrewrk andrewrk added this to the 0.6.0 milestone Apr 18, 2019

@andrewrk

This comment has been minimized.

Copy link
Member Author

commented Apr 30, 2019

Interestingly, this may be related to #130. One current area of unsafety is when you use struct embedding and @fieldParentPtr with an enum telling which kind of type something is with a @ptrCast. If you mismatch ids and types, boom. Potentially the interface/vtable/oop feature, if any, that ends up coming out of #130 could solve this safety issue. Or maybe there could be a more general solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.