In the C implementation, we have to track out_path_len separately from out_path because the C implementation uses a fixed-length buffer to store out_path and uses out_path_len to indicate which bytes are valid.
In JavaScript, there's no reason to store out_path (outPath) as a fixed-width buffer because JavaScript tracks the length of a Uint8Array for us, so outPathLen becomes unnecessary.
Getting rid of outPathLen simplifies the JavaScript semantics because now the caller can just check outPath and know that the entire value is valid.
I implemented this change, and you can see how it looks in my repo on top of the tests in #11:
https://github.com/mtlynch/meshcore.js/compare/test-frame-parse...mtlynch:meshcore.js:no-outpath-len?expand=1
In the C implementation, we have to track
out_path_lenseparately fromout_pathbecause the C implementation uses a fixed-length buffer to storeout_pathand usesout_path_lento indicate which bytes are valid.In JavaScript, there's no reason to store
out_path(outPath) as a fixed-width buffer because JavaScript tracks the length of a Uint8Array for us, sooutPathLenbecomes unnecessary.Getting rid of
outPathLensimplifies the JavaScript semantics because now the caller can just checkoutPathand know that the entire value is valid.I implemented this change, and you can see how it looks in my repo on top of the tests in #11:
https://github.com/mtlynch/meshcore.js/compare/test-frame-parse...mtlynch:meshcore.js:no-outpath-len?expand=1