Importing const char * values using bun:ffi?

[lgarron]

I use bun:ffi to test an FFI built by Rust. This has been working successfully for a while for function calls, but I can't figure out a way to load constant C strings this way.

The constants are generated from here and result in a header file like this:

extern "C" {
  extern const char (*CUBING_EVENT_333);
  extern const char (*CUBING_EVENT_222);
  /* … */
}

I know these constants are in the FFI dylib itself because:

• I'm able to compile a C file that uses these strings and run it successfully.
• If I try to specify these as function symbols to dlopen from bun:ffi, then I'm able to get a JS object. If I specify an invalid symbol instead, I get a Symbol "…" not found error. This shows that bun:ffi is clearly able to recognize the existence of these symbols.

However, I cannot figure out a way to get the C string value from these symbols.

• The types for dlopen(…) seem to be oriented around function calls, and I haven't been able to guess anything to return a symbol for a C string constant.
• I've tried specifying {args: [], returns: FFIType.cstring } for one of these symbols and calling it like a function. This results in:

panic(main thread): Bus error at address 0x130644130
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

• The symbols returned by dlopen(…) all seem to be JS functions. But unlike normal functions, they are logged as e.g. [class CUBING_EVENT_222] yet they don't have a .prototype. I assume this is because of bun implementation details built on the assumption that the symbol is a function.

Is it possible to access the C string values using bun:ffi, or am I missing something?

[190n]

We don't yet have a way to import symbols that aren't functions. You'd be best off defining accessor functions to read these values.

[lgarron]

Okay, that's good to know!

It doesn't make sense to define accessors for these, so I guess I'll invest in testing in other ways for now.

[190n]

Feel free to file a feature request, btw. Right now we're focusing heavily on Node.js compatibility rather than Bun APIs like FFI, but this is a good use case to be aware of for whenever we do pick up work on FFI again.

[lgarron]

Thanks! Filed at: #19175