Question about Linker.Option.isTrivial()

[刘希晨]

Thanks for the feedback. Network protocol do encode variable length data
with a length prefix, which is the most commonly used mechanism to specify
the message boundary so that decoders and encoders would tell which byte
belongs to current message, however, the length data usually just means the
complete message length, not every string variable within it.

For example, in
https://www.postgresql.org/docs/current/protocol-message-formats.html, the
postgresql startup message contains a length prefix indicates the total
length, while within the message body, multiple string were represented as
key-value pair, so we need to call MemorySegment.getString() multiple times
to retrieve them, and we must care about the offset value here.

Thus I think it's quite useful to have a getStringBytes() API in
memorySegment, it would be needed and constantly used.

Best regards.

Maurizio Cimadamore <maurizio.cimadamore at oracle.com> 于2024年1月15日周一 22:58写道：

>
> On 15/01/2024 14:13, Pedro Lamarão wrote:
>
> Em seg., 15 de jan. de 2024 às 09:57, 刘希晨 <benrush0705 at gmail.com>
> escreveu:
>
>
>> I think it's a really common behaviour in network programming, like
>> ByteBuffer, recording the current message offset as its instance variable,
>> so the caller could use get() method multiple times without worrying about
>> its current offset, currently I wrapped MemorySegment in a ByteBuffer-like
>> structure for content reading and writing, but with
>> MemorySegment.getString() and MemorySegment.setString(), the afterwards
>> offset can't be obtained.
>>
>
> In my experience, network protocols will encode variable length data with
> a length prefix, so that you already know how many bytes are there before
> decoding. The alternative, to encode the variable length data with a
> sentinel value, is uncommon.
>
> I was also under this impression - e.g. that network protocols would
> probably want to do the encoding/decoding manually, using more efficient
> encoding (e.g. variable-length string encoding).
>
> That said, the API you propose, which return just the string bytes, is not
> super complex to add in the future, if we still feel like we need something
> like that. Let's keep that in our radars.
>
> Maurizio
>
>
> --
> Pedro Lamarão
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240115/fabc7e5c/attachment.htm>