Hello
I'm trying to take a look at the `v8::ArrayBuffer::Data()` method with the
intention of fixing this
bug: https://bugs.chromium.org/p/v8/issues/detail?id=13488 (and by
extension possibly
unblock https://bugs.chromium.org/p/v8/issues/detail?id=13489)
Put it short: The method returns a null pointer for all zero-length buffers
even when the ArrayBuffer is internally backed by an external pointer.
These sorts of externally backed zero-length buffers are sometimes used in
eg. Node API to pass opaque pointers to and from JavaScript. Getting the
proper pointer requires using the `v8::ArrayBuffer::GetBackingStore()` API,
after which its `Data()` API returns the real external pointer.
I've been trying to track where this difference springs from but haven't
had much success. The `Data()` method calls the `backing_store()` method of
a `i::Handle<i::JSArrayBuffer>` which I _think_ is defined with the
`DEF_GETTER` macro in `js-array-buffer-inl.h` line 48:
DEF_GETTER(JSArrayBuffer, backing_store, void*) {
Address value = ReadSandboxedPointerField(kBackingStoreOffset, cage_base);
return reinterpret_cast<void*>(value);
}
But here I get confused: `ReadSandboxedPointerField` (in
`sandboxed-pointer-inl.h`) seems simple enough that there should be
absolutely no checks against the length of the buffer, nor does it seem
particularly likely for the backing store offset parameter to be somehow
wrong.
If anyone has an idea of where I should look into, that'd be much
appreciated
-Aapo Alasuutari
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-dev/350ede0e-0c6d-433e-b9b3-a85525c7049fn%40googlegroups.com.
