4 ms·

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).

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.

lclarkmichalek 11y ago
Here's an example of that in a lib I've been working on: https://github.com/bluepeppers/libnetfilter_queue/blob/master/src/queue.rs#L47-L102 https://github.com/bluepeppers/libnetfilter_queue/blob/maste...
- cpeterso 11y ago
  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?
  - lclarkmichalek 11y ago
    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".
    - steveklabnik 11y ago
      There's already something that ships with Rust that unmangles some stuff: http://michaelwoerister.github.io/2015/03/27/rust-xxdb.html http://michaelwoerister.github.io/2015/03/27/rust-xxdb.html
tomjakubowski 11y ago
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.
- Rusky 11y ago
  Yes- https://github.com/rust-lang/rust/pull/15831 https://github.com/rust-lang/rust/pull/15831
cpeterso 11y ago
Thanks. I guess using `extern "C"` to imply `#[no_mangle]` would be too cute. :-)

lclarkmichalek 11y ago

Here's an example of that in a lib I've been working on: https://github.com/bluepeppers/libnetfilter_queue/blob/master/src/queue.rs#L47-L102 https://github.com/bluepeppers/libnetfilter_queue/blob/maste...

cpeterso 11y ago
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?
- lclarkmichalek 11y ago
  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".
  - steveklabnik 11y ago
    There's already something that ships with Rust that unmangles some stuff: http://michaelwoerister.github.io/2015/03/27/rust-xxdb.html http://michaelwoerister.github.io/2015/03/27/rust-xxdb.html

tomjakubowski 11y ago

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.

Rusky 11y ago
Yes- https://github.com/rust-lang/rust/pull/15831 https://github.com/rust-lang/rust/pull/15831

cpeterso 11y ago

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