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
Copy file name to clipboardexpand all lines: README.md
+59-25
Original file line number
Diff line number
Diff line change
@@ -48,47 +48,81 @@ Documenation is automatically deployed [here](https://thedan64.github.io/inkwell
48
48
### Tari's [llvm-sys example](https://bitbucket.org/tari/llvm-sys.rs/src/ea4ac92a171da2c1851806b91e531ed3a0b41091/examples/jit-function.rs) written in safe code<sup>1</sup> with Inkwell:
<sup>1</sup> Casting the LLVM JIT function address into a rust function does require a single unsafe transmute, since Inkwell doesn't know what the function signature is. Maybe we can do something about this in the future? In theory, fn_type does contain all the needed info, so whether or not we can do this automagically depends on what rust is capable of. Converting structs, pointers, and other types could be tricky but might be seen as a form of deserialization. See [#5](https://github.com/TheDan64/inkwell/issues/5) for the tracking issue.
120
+
<sup>1</sup> There are two uses of `unsafe` in this example because the actual
121
+
act of compiling and executing code on the fly is innately `unsafe`. For one,
122
+
there is no way of verifying we are calling `get_function()` with the right function
123
+
signature. It is also `unsafe` to *call* the function we get because there's no
124
+
guarantee the code itself doesn't do `unsafe` things internally (the same reason
0 commit comments