StackCheckedPointer is unsound

[kevinmehall]

The documentation describes an assumption Azul's data binding relies on when it bypasses the borrow-checker:

The pointer is inside the boundaries of T to T + size_of::<T>() - as long as T is alive, the pointer points to valid memory.

Unfortunately, nothing in Rust's type system guarantees this. The most obvious counterexample is enum types.

Here's an example showing how code without unsafe can cause an invalid pointer dereference and segfault using the safe interface of TextInput:
https://gist.github.com/kevinmehall/44190fea3e4775c90d175b2bb6c07e53
(this example could do without the RefCell if it were mutated elsewhere, in a callback or something).

[fschutt]

Very good point, thanks for reporting. Yes, it is unsound and there currently seems to be no way of preventing this other than common sense (not to modify the data model within the layout() function). To "fix" this, it might be possible to store extra information such as enum discriminant ID and TypeId of the original type, to at least safeguard better against these issues (for example, a trait that could report the sizes, offsets and enum IDs automatically from the compiler at compile time, then check whether the pointer is contained inside of a RefCell or whether a callback has modified the enum variant). Sort of like RTTI, but without type information, only size and offset information.

What basically needs to happen is some kind of check in the layout function whether the pointer that the callback has acted on could be or has been modified from the time of creation to the time of invokation.

[o01eg]

Could it be implemented via Pin?

[tobz1000]

As I understand it, Pin is a generalisation of what StackCheckedPointer is trying to achieve - and would allow previously-proven self-referential structures to be used where possible.

Is there any reason not to allow users to provide a &mut TextInputState-getter function, rather than a direct reference to the field; e.g. textInput.bind(window, |model| &mut model.text_input, &mut model)? I imagine the safety gain would be worth the small performance hit in many instances.