Neat Rust Tricks: Passing Closures to C
blog.seantheprogrammer.com
Neat Rust Tricks: Passing Closures to C
1–10 of 69 posts
Re: Neat Rust Tricks: Passing Closures to C
#2Is this a neat trick or just standard operating procedure for calling C from ? As it was billed as a trick, I was expecting some sort of runtime code generation to pass the data pointer and some jump instruction to jump to the right spot and unpack the data pointer.
Maybe I just overcomplicate things ;-)
Re: Neat Rust Tricks: Passing Closures to C
#3How does this relate to nested functions in C? (And resulting “infectious executable stacks”?)
Re: Neat Rust Tricks: Passing Closures to C
#4How does this relate to nested functions in C? (And resulting “infectious executable stacks”?) https://nullprogram.com/blog/2019/11/15/
The problems there don't apply I believe because Rust closures don't require an executable stack.
Re: Neat Rust Tricks: Passing Closures to C
#5How does this relate to nested functions in C? (And resulting “infectious executable stacks”?) https://nullprogram.com/blog/2019/11/15/
It doesn't. This is just showing the normal way that callbacks are implemented in vanilla C and how you would make that programming pattern interoperate with Rust closures. Neither one relies on the compiler trickery/runtime code generation described in the earlier article.
Re: Neat Rust Tricks: Passing Closures to C
#6How does this relate to nested functions in C? (And resulting “infectious executable stacks”?) https://nullprogram.com/blog/2019/11/15/
The executable stack trick is only required if you want to implement closures that can be called as if they were plain C functions, with only a function pointer and no extra (void *) argument.
Re: Neat Rust Tricks: Passing Closures to C
#7How does this relate to nested functions in C? (And resulting “infectious executable stacks”?) https://nullprogram.com/blog/2019/11/15/
It doesn't relate to it at all. The issues around linking to problematic object files mentioned in that article will apply to Rust as well, but that's unrelated to the subject of this article, it's a property of the linker you're using and the toolchain used to compile whatever C dependencies you have
Re: Neat Rust Tricks: Passing Closures to C
#8How does this relate to nested functions in C? (And resulting “infectious executable stacks”?) https://nullprogram.com/blog/2019/11/15/
C doesn't have nested functions - they are a GCC extension.
Re: Neat Rust Tricks: Passing Closures to C
#9How does this relate to nested functions in C? (And resulting “infectious executable stacks”?) https://nullprogram.com/blog/2019/11/15/
The problems there don't apply I believe because Rust closures don't require an executable stack.
That's correct - a Rust closure generally [1] can't be converted to a function pointer as it requires both code and state.
Re: Neat Rust Tricks: Passing Closures to C
#10Earlier quoted context omitted.
The problems there don't apply I believe because Rust closures don't require an executable stack.
That's correct - a Rust closure generally [1] can't be converted to a function pointer as it requires both code and state. [1] https://github.com/rust-lang/rust/issues/39817
The whole point of jgtrosh's link is that there is a way to hide data behind a function pointer, so Rust could convert any closure to a function pointer. But it requires writable-and-executable memory, so it's a pretty bad idea (in GCC's implementation, that memory is on the stack, which is an extra bad idea, but i don't think it needs to be).