Flatbuffers: [Rust] Request: If bounds checking is removed, please annotate unsafe buffer access as unsafe

[casey]

The documentation states:

Access of untrusted buffers
The generated accessor functions access fields over offsets, which is very quick. These offsets are used to index into Rust slices, so they are bounds-checked by the Rust runtime. However, our Rust implementation may change: we may convert access functions to use direct pointer dereferencing, to improve lookup speed. As a result, users should not rely on the aforementioned bounds-checking behavior.

The above quote sounds like the implementation may change without warning to use direct pointer access. If the implementation does change in this way, please annotate any functions which may cause unsafe behavior (such as unchecked pointer access) as unsafe.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity for 6 months. It will be closed if no further activity occurs. Thank you for your contributions.

[casey]

I notice that this has been marked as stale. However, I think this is a very important issue. The docs say:

we may convert access functions to use direct pointer dereferencing, to improve lookup speed

The possibility that an API may become unsafe in the future is pretty worrisome.

I would suggest that if access speed turns out to be an issue, new, unsafe functions should be added letting users opt-in to unsafe accesses, leaving the existing, safe functions untouched.

[github-actions[bot]]

This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.

[rw]

@casey We actually want to remove as much unsafe usage from the library as we can, so it's less likely that we'll remove bounds checking in the near future. And, to your concern, if we do remove bounds-checking eventually, we'll mark it as unsafe.

[casey]

That's great! I opened a PR to remove that section from the docs, if it's not the case that users have to be aware that the existing interface might become unsafe, it seems like it can be removed: #5969.