Investigate use of unsafe and panicking

[ionut-arm]

At the moment, our methods implemented on Context appear to be safe for clients of the crate to use, but it might not be so. We should decide what unsafe behaviour means for us and what functionality we report as (un)safe.

We should also look into our uses of unwrap and try to reduce them as much as possible.

[hug-dev]

See https://github.com/rust-secure-code/safety-dance for unsafe
Maybe there is a way (a Cargo plugin?) to search for all unsafe blocks in the current crate and in dependencies? In the above link they seem to do it manually.

[hug-dev]

Also: https://rust-lang.github.io/unsafe-code-guidelines/
This will be useful for parallaxsecond/parsec#73 as well

[ionut-arm]

We have to decide what kind of guarantees we provide when we offer a safe function in an interface and probably the easiest one to reason about would be something like

This code will not panic or crash unless some memory is corrupted or if the underlying software stack crashes due to reasons outside of our control. All other errors will be returned with appropriate insight, as a Result

I think this leaves us with the sole responsability of being the middle-man, but not putting any pressure related to checking the arguments that we pass down (apart from a process safety perspective) - and by this I'm only talking about the Context structure.

For any abstractions, we would definitely need to make sure that the intended operations work out of the box, barring invalid arguments (that we validate ourselves).

@hug-dev - does that make sense?

[hug-dev]

I think so, preventing invalid argument to be given to the underlining unsafe C code is the main point to me. We need to make sure that at any given moment, we are using the subset of inputs that make the stack safe to execute, both in memory and threads terms.