Stream: git-cranelift

Topic: cranelift / Issue #300 Consider alternative methods for w...

view this post on Zulip GitHub (Feb 12 2020 at 17:11):

cfallin commented on Issue #300:

FWIW, this bit me while prototyping ARM64 (see issue cfallin/cranelift#8) -- we should definitely look at safer API options. Perhaps just a ctor that takes a slice, and bounds-checks as it generates? Was the intent of the initial design to avoid the bounds-check overhead?

view this post on Zulip GitHub (Feb 28 2020 at 23:24):

alexcrichton transferred Issue #300:

Currently, binemit has its own CodeSink trait for writing binary data. It isn't entirely satisfying, in part because it's an unsafe interface -- it doesn't perform bounds checking on the underlying data. While we can provide relatively safe interfaces to protect users from misusing the API, it's harder to be absolutely certain that the number of bytes compile says a function needs is the number of bytes emit_to_memory actually writes for that function.

One option would be to provide a safe checked version of MemoryCodeSink. However, it's also worth considering evaluating available crates that provide low-level byte buffer writing functionality, including:

Last updated: Nov 22 2024 at 16:03 UTC