#FFI to map stdvector to UInt8List

1 messages · Page 1 of 1 (latest)

final mantle
#

I'm trying to make an interface where I expose a std vector to js by returning a pointer to a struct containing two 64bit ints containing [vec.data(), vec.size()], I then map this as a BigInt64List to get the ptr and size. When I map this with toArrayBuffer I get a segfault trying to access it. Is there a documented way to do this?

celest sedge
#

is the struct heap allocated?

final mantle
#

yes

#

I can view the struct just fine

# 
console.log("chunk is", view, typeof view);
var buf = new BigInt64Array(toArrayBuffer(view, 0, 16), 0, 2);
console.log("buf is", buf);

var data = Number(buf[0]);
var size = Number(buf[1]);
console.log("size is", size, "data is", data, "type is", typeof data);

var buf2 = new BigInt64Array(toArrayBuffer(data, 0, 16), 0, 2);
console.log("buf2 is", buf2);
#

gives me

# 
chunk is 104871824 number
buf is BigInt64Array(2) [ 102776112n, 1000n ]
size is 1000 data is 102776112 type is number

Thread 1 "bun" received signal SIGSEGV, Segmentation fault.
#

can bun only access pointers passed through the FFI interface as "FFIType.ptr" ?

#

like not arbitrary pointer arithmetic?

celest sedge
#

it should still be possible as a bigint that way but ptr has better test coverage

#

I would suggest returning it as a ptr and then for length do another pointer as an argument type

#

so from JS

#

oh wait

#

it's BigInt64Array

#

you want

#

those are being interpreted as signed integers

#

not as unsigned integers

final mantle
#

BigUint64Array didn't work, but two calls to get raw and size worked fine

celest sedge
#

its generally easier to have JS control the lifetime instead of C++, like passing the pointer to C++ and then reading it back

final mantle
#

yeah i have a refcounting interface where js controls the lifetime

#

I think bun must stash some metadata in the js 'number' object returned by a C function

#

i have two values, both are typeof == "number", both print 134090032 when printed, one works fine with toArrayBuffer, the other causes a segfault

#

oh wait you wrote the code 😄

#

so what's the catch? how do the to numbers differ?

celest sedge
#

sorry just saw this

#

are you sure that 0, 16 is right

#

would it possibly be 8 byte aligned

#

i guess it would still be

#

0, 16 in that case

#

could you check if the pointer is correct

#

do you possibly have some pointer tagging going on

#

in your code