This is a PR, with the intention of starting/continuing the discussion about bringing FFI into node/iojs core.

Overall, the biggest benefit to integrating an FFI interface to node-core is that we can avoid C++ compiled addons, for the common case (where extreme performance requirements would be the uncommon case). No more compiling is huge for the UX, especially on Windows.

As of now, this PR adds some low-level functions to the Buffer object. I believe that these are the building blocks necessary to remove the C++ compiled portion of ref, and leaves room to implement other kinds of native interfaces (we could build js-ctypes API on top of these low-level functions as well… I'm planning on doing exactly that if this gains momentum!)

New Buffer APIs

readInt64BE(), readInt64LE(), readUInt64BE(), and readUInt64LE()

Reads an (u)int64 value from the Buffer. Similar to the other read* functions, but if the int64 value falls outside the JS Number max value (±9007199254740992) then a String will be returned instead of a Number. This falls in-line with most Int64 library APIs, including the ctypes Int64 constructor, which accepts either a Number or String.

writeInt64BE(), writeInt64LE(), writeUInt64BE(), and writeUInt64LE()

Complimentary to the read* functions, these allow int64 range integers to be written to Buffer instances. A JS Number may be passed in, and it will be written accordingly. Alternatively, a JS String may be passed in and it will be converted to an (u)int64 via strtoll/strtoull and then written to the Buffer instance (there would probably be value in accepting a Buffer instance that already has a (u)int64 written to it, but that's not currently implemented).

readPointerBE() and readPointerLE()

These functions create a Buffer (pointer) instance from the memory address written to the parent buffer. This is essentially the "dereference" operator in C. Very important for interacting with C libraries via FFI!

Not implemented at the moment, but we could add an optional callback function here that would be invoked during the Buffer free callback, which the user could hook on to to free allocated memory from a C library, for example. This is easy to add if there's no objections.

writePointerBE() and writePointerLE()

The compliment to the readPointer* functions. Essentially the "reference" operator in C. Allows the user to write the memory address of one Buffer instance to an offset in another buffer.

address()

Returns a String representation of the hex address of the pointer in memory.

inspect()

The REPL inspect() function for Buffer gets a cute little update as well thanks to the new address() function. We include the hex pointer address after the constructor name:

> new Buffer(8)
<Buffer@0x10187aa08 00 20 00 00 00 00 00 00>

Missing pieces

So like mentioned above, this is really just the low-level C functionality that we need added as methods to Buffer. There's still some new interfaces we'll need to expose in order to implement a fully-featured FFI interface, or implement js-ctypes. Perhaps we can hash out the details of these in this thread as well:

• sizeof mapping for standard types (int, double, etc.), for allocing Buffer instances of the correct size. Perhaps require('os').sizeof? See [Discussion] FFI - export os.sizeof and os.alignof mappings #1759.
• -alignof mapping for standard types (int, double, etc.), for creating structs, etc. Perhaps require('os').alignof? See [Discussion] FFI - export os.sizeof and os.alignof mappings #1759.
• dynamic library loader (uv_dlopen() and friends, but exposed to JS). Perhaps require('_dl') or something? There is the dlopen package which we could get inspiration from. See [Discussion] FFI - require('dlopen') - libuv dynamic library loader binding #1762. Additionally, this could allow for process.dlopen() (the .node module loader) to be re-written in 90% JavaScript, which would be kind of cool.
• low-level libffi bindings (bundle the gypified libffi into the node binary, expose a very basic JS interface). Perhaps require('_ffi')? node-ffi is great, but it's a bit too high-level for core IMO. It aims to be a more complete FFI solution, a la ctypes, rather than simple low-level bindings in which ctypes could be implemented on top of.. See [Discussion] FFI - require('ffi') - libffi low-level binding #1865

(not sure about the _ prefix on ffi and dl... just wanted to be conscious about not trampling over the existing npm package names)

Obviously, we'll need to compliment this with good docs and tests (some of which I could pull from ref most likely) before it's ready for merge. I just wanted to get this PR open first to see if there's momentum, and other comments/adjustments that will be needed to be addressed as well. Let's get the 🔮 rolling!

Thanks for reading. Cheers! 🍻

/cc @bnoordhuis @piscisaureus @rvagg @indutny @isaacs @kkoopa @trevnorris @rauchg @saghul @tracker1 @nodejs/build et al.