Hacker News Reader

Comment by cpeterso | Hacker News Reader

What happens if the double_input Rust function is declared extern but not no_mangle? When would you want a mangled extern Rust function?

View on HN

If you omit the `#[no_mangle]` definition then the compiler will end up emitting a mangled symbol (e.g. one with a long hash at the end that's hard to guess).

Many C APIs take a callback function pointer, which in rust has the type `extern fn()`, and this is the primary use case for an `extern` function defined in Rust which doesn't have `#[no_mangle]` on it.

Here's an example of that in a lib I've been working on: https://github.com/bluepeppers/libnetfilter_queue/blob/maste...

Thanks for the example. What is the advantage of using an unmangled extern fn as a C callback? That the user-friendlier unmangled function name will appear in stack traces or can more safely be called from other Rust code?

True, though it wouldn't be hard to write a GDB extension to unmangle the names (I know D had this from quite early in it's lifetime). In general, I leave unmangled names to things that are part of the external interface: when unmangling the name, I'm explicitly saying "this symbol's name is part of the contract I have with user of this library".

There's already something that ships with Rust that unmangles some stuff: http://michaelwoerister.github.io/2015/03/27/rust-xxdb.html

Can you make external "C" callback functions generic? The function itself I mean, not the signature of the FFI function that takes the callback. If so, there's a great use case for not mangling C callbacks.

Yes- https://github.com/rust-lang/rust/pull/15831

Thanks. I guess using `extern "C"` to imply `#[no_mangle]` would be too cute. :-)

Reply on news.ycombinator.com