On Tue, 29 Sep 2020 19:20:42 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> Also in that last example, it seems to suggest that the second octet string >> is nested within the first one since it >> sits at a second indent layer. They are both primitives completely covered >> by their two byte values so shouldn't they >> sit at the same indentation level? Or is the indentation not there to >> suggest nested substructures and is more for >> separation between elements? Or is this what you mean by "lost an indent"? >> Also, should the end of content be at the >> same indentation level as the initial indefinite length encoding? > >> Also in that last example, it seems to suggest that the second octet string >> is nested within the first one since it >> sits at a second indent layer. They are both primitives completely covered >> by their two byte values so shouldn't they >> sit at the same indentation level? Or is the indentation not there to >> suggest nested substructures and is more for >> separation between elements? Or is this what you mean by "lost an indent"? >> Also, should the end of content be at the >> same indentation level as the initial indefinite length encoding? > > Yes, all of the enclosed items should be at the same indent level. (A bug as > it turns out). > I chose to indent the END-OF-CONTENT line at the same level to terminate the > list of tag-values at that level > All of the items enclosed are at the same level. > > The updated output is: > 0000: 24 80 ; UNIVERSAL CONSTRUCTED > OCTET STRING [INDEFINITE] > 0002: 04 02 61 62 ; OCTET STRING [2] > 'ab' > 0006: 04 02 63 64 ; OCTET STRING [2] > 'cd' > 000a: 00 00 ; END-OF-CONTENT Regarding the end-of-content identifier, that looks good. Thanks for fixing the indentation for the right-side ASN.1 interpretation of the bytes. My only remaining question is whether the corresponding hex dumps on the left should match the indentation levels as well. I don't have a strong opinion either way on that one but if you're indenting for each element at the same nest level it seems like that could potentially chew up a lot of horizontal space. Was the extra indentation for the second octet string done for readability? ------------- PR: https://git.openjdk.java.net/jdk/pull/268
