Utilizing C SDK from Bun FFI fails but regular C script utilizing the SDK with the same logic succeeds

Resolving Discrepancies between C SDK Utilization in Bun FFI and Regular C Script

---

An underlying issue arose when attempting to invoke the C SDK via Bun's FFI, resulting in failure, while a standalone C script using the same SDK and logic executed successfully. The root cause behind this disparity was twofold:

1. Null-Termination of Strings:

   Strings provided through Bun's FFI must be null-terminated to adhere to C's string conventions. This can be achieved by appending a zeroed buffer or employing the nul escape character (\0) or its hex equivalent (\x00). Examples in Bun:

     const nul = Buffer.from([0]);
     const buf = Buffer.concat([Buffer.from("hello"), nul]);
     

     const buf = Buffer.from("hello\0");
     

     const buf = Buffer.from("hello\x00");
     



2. Misinterpretation of Pointer Handling in Bun's FFI:

   In C, a pointer variable holds the memory address it points to, which can be directly referenced. However, in Bun's FFI, obtaining the value of a pointer (the address it points to) requires reading bytes from the pointer. Meanwhile, passing the raw pointer variable in Bun (ptr) is akin to passing the address of the pointer itself (similar to using & in C). To obtain the address the pointer points to in Bun, we must read the bytes from the memory where our pointer variable is stored (read.ptr(ptr)). Here's an example:

     import { dlopen, ptr, FFIType, read } from "bun:ffi";
   
     const sdk = dlopen("path/to/sdk", {
       someMethod: FFIType.ptr,
       someOtherMethod: FFIType.ptr
     });
   
     const ptr = ptr(new UInt8Array(8));
     sdk.someMethod(ptr);
     sdk.someOtherMethod(read.ptr(ptr));