[External] : Re: MemorySegment APIs for reading and writing strings with known lengths

[Liam Miller-Cushon]

Thanks. I am convinced :)

On Wed, Nov 12, 2025 at 3:30 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 12/11/2025 11:40, Liam Miller-Cushon wrote:
>
> For the non-\0 terminated strings, you have the String-based
>> MemorySegment::copy I described - e.g.
>>
>> void copy(String srcString, Charset srcCharset, int srcIndex, MemorySegment dstSegment, long dstOffset, int length);
>>
>> With this, we also have two cases:
>>
>> * if the charset is compatible with the string buffer, we just bulk-copy
>> the string buffer (or a portion of it) into the dest segment
>> * otherwise we can encode the srcString directly into the dest segment
>>
> Thanks! I think I'm caught up now. My misunderstanding was whether
> MS::ofString was being suggested instead of and not in addition to the bulk
> copy.
>
> Ah, gotcha.
>
> I think MS::ofString is a possible add-on. To be fair, since writing the
> document I think we've grown a little colder on it, as such a view would
> make for a pretty big footgun, as it would allow a native function (invoked
> via critical downcall handle) to directly modify the string buffer (at
> least in some cases). There's also some question about how
> `MemorySegment::equals` should work in this case, as `equals` for heap
> segments takes into account the identity of the underlying heap object.
>
> So, if we could get there with the new `getString`/`copy` + maybe some way
> to determine the length of an encoded string, I think it would be
> preferrable/less risky. We could always add `ofString` later, if we find a
> way to address and/or mitigate the issues above.
>
> Maurizio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20251112/6d4207f7/attachment.htm>