You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The recent PR 4753 changes message encryption to use an in-place BytesMut construction to avoid unnecessary allocation. When applying padding prior to encryption, it reserves extra space in the buffer to accommodate the padding before adding it. However, it reserves too much space.
The documentation for BytesMut indicates that reserve should be provided the number of additional bytes needed in the buffer, not the total number of bytes needed. As a result, the current code appears to allocate the buffer to accommodate twice the message length plus padding, which appears to negate the desired benefit of using the BytesMut approach.
Changing the linked line to message.reserve(padding_length); seems to be sufficient to avoid unnecessary reallocation, while accounting for the extra space needed for padding.
The text was updated successfully, but these errors were encountered:
The recent PR 4753 changes message encryption to use an in-place
BytesMut
construction to avoid unnecessary allocation. When applying padding prior to encryption, it reserves extra space in the buffer to accommodate the padding before adding it. However, it reserves too much space.The documentation for
BytesMut
indicates thatreserve
should be provided the number of additional bytes needed in the buffer, not the total number of bytes needed. As a result, the current code appears to allocate the buffer to accommodate twice the message length plus padding, which appears to negate the desired benefit of using theBytesMut
approach.Changing the linked line to
message.reserve(padding_length);
seems to be sufficient to avoid unnecessary reallocation, while accounting for the extra space needed for padding.The text was updated successfully, but these errors were encountered: