Nashatyrev edited a comment on issue #88:
URL: https://github.com/apache/incubator-tuweni/issues/88#issuecomment-657482389
> `Bytes.wrapByteBuf(buffer, 0, buffer.readableBytes())`
The more correct usage then would be: `Bytes.wrapByteBuf(buffer,
buffer.readerIndex(), buffer.readableBytes())`
> I’d say the expected output is 100. A byte buffer is not variably sized,
but rather sized at creation. Its content is 100 bytes. You just have 99 that
are undefined.
I would tend to disagree here:
```java
ByteBuf buf = Unpooled.buffer().writeByte(1);
Bytes bytes = Bytes.wrapByteBuf(buf);
System.out.println(bytes.size());
```
This would output `256`. If you write `300` bytes, the output would be
`512`. The buffer size is not static and managed internally. Another Netty
version may potentially allocate other buffer size by default which makes
`Bytes.wrapByteBuf()` behavior inconsistent.
Just another sample: that would output `1`
```java
ByteBuf buf = Unpooled.buffer().writeByte(1);
ByteBuf wBuf = Unpooled.wrappedBuffer(buf);
Bytes bytes = Bytes.wrapByteBuf(wBuf);
System.out.println(bytes.size());
```
The 'true' `ByteBuf` content starts at `readerIndex` and has size
`readableBytes`. While other buffer content is still available via `ByteBuf`
API it should be treated as junk. When allocating buf via
`Unpooled.directBuffer()` you may even potentially have uninitialized memory in
the rest of the buffer.
I see the option of `Bytes.wrapByteBuf(ByteBuf, int, int)` but I still think
the method `Bytes.wrapByteBuf(ByteBuf)` default behavior should be to wrap only
the readable content of `ByteBuf`.
I would reopen the issue for the next round of discussions
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tuweni.apache.org
For additional commands, e-mail: dev-h...@tuweni.apache.org
