<div dir="ltr"><div dir="ltr">Em seg., 15 de jan. de 2024 às 12:57, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> escreveu:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <p>On 15/01/2024 15:23, 刘希晨 wrote:<br></p>
    <blockquote type="cite">
      <div>For example, in <a href="https://urldefense.com/v3/__https://www.postgresql.org/docs/current/protocol-message-formats.html__;!!ACWV5N9M2RV99hQ!MyEp6roAVJiCW7ICOb0qsj7sTbl0-6FMpSP_cUorkgFXlpYaIVusJQFoY7eOtiEupFUi3lUU5xivRt9F_QCYn96J52eW$" target="_blank">https://www.postgresql.org/docs/current/protocol-message-formats.html</a>,
        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.</div>
      <div><br>
      </div>
      <div>Thus I think it's quite useful to have a getStringBytes() API
        in memorySegment, it would be needed and constantly used.</div>
    </blockquote>
    <p>Thanks for the pointer. It is indeed a case of "back to back"
      strings.</p>
    <p>One possible workaround, with current API, is to simply get the
      string first, then get the string bytes (and that would be your
      "next offset").</p></div></blockquote></div><div><br></div><div>I think that a validating parser for such protocols must scan for the sentinel value before decoding the variable length element to avoid decoding invalid messages.</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>