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
Currently, most protodef implementation assume pstring is utf-8 or ASCII. Fortunately, that's compatible with a lot of protocols. But this is a big shortcoming.
It would be a good idea to allow the protocol author to write what encoding a pstring is in. I wonder if there's a standard about encoding names somewhere ? A quick look gave me https://encoding.spec.whatwg.org/#names-and-labels .
pstring's count argument should count the byte length, regardless of the encoding. I'm fairly sure this is how most protocol send strings.
cstring has a similar problem. We should limit it only to single-byte encodings, given it is meant to be compatible with C char*.
The text was updated successfully, but these errors were encountered:
roblabla
changed the title
Add encoding field to pstring (and cstring?)
Add encoding field to pstring (and cstring?)
Feb 27, 2017
Currently, most protodef implementation assume pstring is utf-8 or ASCII. Fortunately, that's compatible with a lot of protocols. But this is a big shortcoming.
It would be a good idea to allow the protocol author to write what encoding a pstring is in. I wonder if there's a standard about encoding names somewhere ? A quick look gave me https://encoding.spec.whatwg.org/#names-and-labels .
pstring's
count
argument should count the byte length, regardless of the encoding. I'm fairly sure this is how most protocol send strings.cstring has a similar problem. We should limit it only to single-byte encodings, given it is meant to be compatible with C
char*
.The text was updated successfully, but these errors were encountered: