The writeStringNT code when not given an offset argument is correct as it uses the writeOffset for placing the null terminator, but with an offset it is incorrect. The insertStringNT is always incorrect.
You will have to switch the use of value.length for Buffer.byteLength() in those two places.
Your implementation could be simplified by just appending '\0' to the string and passing it to writeString/insertString. There will be no functional difference in all encodings except UTF-16, where the null terminator will become two-byte long:
If you go with this approach, you will also have to special-case the readStringNT code for UTF-16 (and all its aliases, to avoid hardcoding them you might check the length of an encoded '\0') to look for the even-aligned two-byte null, but that is incorrect currently anyway: https://github.com/JoshGlazebrook/smart-buffer/issues/23
I guess there may be an argument for the Buffer.byteLength() approach (while perhaps still changing the terminator to two-byte in utf16) to avoid temporary string values with the concatenation approach hurting performance, but I can't imagine how long the strings would need to be for this to become noticeable... Probably a non-issue.
The
writeStringNT
code when not given an offset argument is correct as it uses the writeOffset for placing the null terminator, but with an offset it is incorrect. TheinsertStringNT
is always incorrect. You will have to switch the use ofvalue.length
forBuffer.byteLength()
in those two places.Your implementation could be simplified by just appending
'\0'
to the string and passing it towriteString
/insertString
. There will be no functional difference in all encodings except UTF-16, where the null terminator will become two-byte long:If you go with this approach, you will also have to special-case the
readStringNT
code for UTF-16 (and all its aliases, to avoid hardcoding them you might check the length of an encoded'\0'
) to look for the even-aligned two-byte null, but that is incorrect currently anyway: https://github.com/JoshGlazebrook/smart-buffer/issues/23I guess there may be an argument for the
Buffer.byteLength()
approach (while perhaps still changing the terminator to two-byte in utf16) to avoid temporary string values with the concatenation approach hurting performance, but I can't imagine how long the strings would need to be for this to become noticeable... Probably a non-issue.