You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would make more sense for this to read x characters rather than bytes. I don't really see a reason to read an exact number of bytes as a string (if need be this can be done with a simple read(x) and then getString), with Unicode strings this is just making it more likely to decode badly.
The text was updated successfully, but these errors were encountered:
That depends on a protocol used to encode Bytes. If your protocol tells you that a string is encoded in the next N bytes, then it's more convenient to readString using the number of bytes.
varstr=input.read(nBytes).getString(0, nBytes); // or .toString() if we're keeping it
My concern is mostly that there currently no method to read N characters apart from reading bytes until you get a valid Unicode string that is of the correct length.
We can't read N characters, that would be quite inefficient as we would have to read byte by byte.
Also, in binary protocols the string length is usually in bytes not in characters. Finally, that would be a very huge problem wrt backward compatibility.
Please update the unit tests accordingly and close this issue.
(some:haxe.io.Input).readString(x, UTF8)
I think it would make more sense for this to read
x
characters rather than bytes. I don't really see a reason to read an exact number of bytes as a string (if need be this can be done with a simpleread(x)
and thengetString
), with Unicode strings this is just making it more likely to decode badly.The text was updated successfully, but these errors were encountered: