Feature request: usage as a crate or machine-readable output

[connor4312]

I came across this library when looking for binary diff implementations. This is pretty nice implementation and incredibly fast. I was interested in using it as a library for a hex editor, and I was wondering if you had any appetite to expose some of its functionality as a crate. Or, alternatively and perhaps more simply, a more machine-readable --print option for consumption in other tools.

I'm happy to spend some time putting together a PR for either of these approaches if you think they would make sense 🙂

[8051Enthusiast]

Sure, I think the alignment part is easily separable from the other stuff so I could just make it its own crate anyway.
There's one thing with the wfa2 backend though: right now, wfa2 doesn't seem to be buildable with msvc (it depends on pthreads and there's a bunch of (unused?) unix headers in common.h), would that be a problem? Or maybe there's a workaround for that?

[connor4312]

I haven't honestly tried it yet on Windows. Not having Windows support at all may exclude our use case, but missing a few platforms is fine. WFA2 already only supports 64 bit architectures which excludes it from being entirely portable in a wasm binary (as so far browser vendors have only shipped wasm32).

Edit: turns out wasm memory64 is actually somewhat available behind a flag in all browsers. Maybe an avenue sooner than I thought!

[8051Enthusiast]

I should probably also clarify, it does build on windows, not using the msvc but the windows-gnu target. I don't know how electron/vscode interfaces with rust, but it would probably complicate ABI matters and/or make the build more complicated.
I do agree that targetting wasm64 sounds promising

[8051Enthusiast]

I have factored the alignment part out into a library, you can read the documentation here.
Tell me if there's any interface missing that you'd need.

I looked into wasm64, but it seems like it is quite poorly supported for rust at least, so if you wanted to use it, you'd probably have to use the WFA2 library directly using C (although I don't know the state of C tooling for wasm64 either).
However, it seems like WFA2 doesn't actually need pthread, that was just a leftover from the OpenMP support in the build script.
I did need to make some slight adjustments to some intrinsics and small stuff like that, but it now builds using msvc.
I will probably try to upstream that commit later.