On Tue, 14 Feb 2023 17:17:53 GMT, Jim Laskey <jlas...@openjdk.org> wrote:
>> To me it sounded like it wanted to say: Since the `ATTRIBUTE_END` isn't a >> full byte (only 5 bits in a byte), it might be represented as a non-zero >> value. For example a byte containing `0x07` would equally be `ATTRIBUTE_END` >> as would a zero byte or a `0x01` byte. `ATTRIBUTE_END` is a `kind` which is >> encoded with the *most* significant `5` bits. Yet, `ATTRIBUTE_END` isn't a >> full byte. The least significant `3` bits in the byte represent the `length >> - 1` - of bytes - in the attribute stream for offset values. That, to me, >> also would suggest that comparing it to a zero byte value is not sufficient >> to detect `ATTRIBUTE_END`. > > I meant that an attribute can have zeros in the non-header portion of the > attribute data. Got it. How about we change this comment from: // - Even though ATTRIBUTE_END is used to mark the end of the attribute stream, // streams will contain zero byte values to represent lesser significant bits. // Thus, detecting a zero byte is not sufficient to detect the end of an attribute // stream. to: // - Even though ATTRIBUTE_END (which might be encoded as a zero byte) is used to // mark the end of the attribute stream, streams will contain zero byte values in the // non-header portion of the attribute data. Thus, detecting a zero byte is not // sufficient to detect the end of an attribute stream. ? The phrase "to represent lesser significant bits" and mention of `ATTRIBUTE_END` is throwing me off. ------------- PR: https://git.openjdk.org/jdk/pull/12533
