From 482f0267edfba056ffa181333f9d65972d834175 Mon Sep 17 00:00:00 2001 From: Deirdre Connolly Date: Wed, 7 Oct 2020 10:37:15 -0400 Subject: [PATCH] Clarify length field size in bytes --- zip-0302.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0302.rst b/zip-0302.rst index 30670d11..253dad09 100644 --- a/zip-0302.rst +++ b/zip-0302.rst @@ -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: