RFR: 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp [v2]

[Severin Gehwolf]

On Tue, 14 Feb 2023 17:17:53 GMT, Jim Laskey <jlaskey at 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