zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Clarify length field size in bytes

This commit is contained in:
Deirdre Connolly 2020-10-07 10:37:15 -04:00 committed by GitHub
parent 03675c4c4a
commit 482f0267ed
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
zip-0302.rst
View File

@ -40,7 +40,7 @@ This ZIP refines the specification of the third case.
+ decode it as UTF-8 (replacing any incorrect UTF-8-encoded byte sequences with the replacement character U+FFFD), and display it to the user as a human-readable string.
+ If byte 0's value is 0xF5, then the reader MUST:
+ Interpret the next few bytes (1 to 9 of them) as a 64-bit unsigned variable-length integer [#Bitcoin-CompactSize]_, and use it as an arbitrary application-defined "type" field.
+ Interpret the next bytes (1 to 2 of them) as a 16-bit unsigned ULEB, and use it as the length field.
+ Interpret the next bytes (1 to 2 of them) as a 16-bit unsigned ULEB, and use it as the length field. (The length can be at most 510 bytes due to the overall memo length, and that is why the length field can only be 1 or 2 bytes.)
+ If 1 + the number bytes used for the type field + the number of bytes used for the length field + the length > 512 then error out, i.e. do not do any further processing of the memo, and do not return any information about the memo to the caller other than the fact that it was incorrectly formatted.
+ Inspect the padding after the end of the indicated length, and if it contains anything other than bytes of value 0x00 then error out.
+ Return to the caller a 3-tuple of the following data: