You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IMO, for some particularly critical (paranoid?) software, it makes sense to protect pointers transmitted to a foreign language. Is it in the scope of this guide? as a rule, I don't think so... it's not pragmatic enough.
With respect to the stack/heap divide, it is still sensible today to consider stack pointers more dangerous. Again, not always possible for various reason.
For the how, it really depends on what you're trying to protect:
A transparent object that the foreign side will manipulate,
A pointer to an opaque type that the foreign side may manipulate through a C API to Rust.
In the former, without OS support, canary seems the way to go.
In the latter, signed pointers (or tagged pointers) makes more sense.
After PR #29 and following up discussions:
For the how, see @danielhenrymantilla's example in #29 (comment)
The text was updated successfully, but these errors were encountered: