Modeling C-Strings with MemoryLayout?

[Gavin Ray]

Ah, I was afraid the answer might be something like that

My interest was in trying to model the types of Postgres Wire Protocol as
MemoryLayout types
Unfortunately, several of the types have variable-length strength fields in
them

If you ctrl+f here, there are some ~30-ish fields in total which are
"String" null-terminated C-string types =/
PostgreSQL: Documentation: 15: 55.7. Message Formats
<https://www.postgresql.org/docs/current/protocol-message-formats.html>

Of course for these specific fields/types exceptions can be made but it
triggers my OCD, ha

On Wed, Dec 28, 2022 at 8:40 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Gavin,
> while something like that is possible, that would not be the best way to
> use memory layouts. I believe the sweet spot for memory layout is to
> capture data types whose size can be determined statically.
> Variable-length data structures don't fall in this case (another
> relatively common case is C struct which end with a variable-length
> array). While it would be possible, with some heroics, to enhance var
> handles to take extra dynamic access coordinates at runtimes, the
> condition under which this would be possible are very limited.
>
> Perhaps it would be better to understand what you are trying to achieve
> by modelling a C string with a memory layout? Often, passing strings as
> opaque pointer just works. Note also that the FFM API provides some
> helper functions to allocate and dereference NULL terminated strings -
> see MemorySegment::get/setUtf8String, as well as
> SegmentAllocator::allocateUtf8String.
>
> Cheers
> Maurizio
>
>
>
> On 25/12/2022 19:24, Gavin Ray wrote:
> > Is it possible to model C-Strings with MemoryLayouts?
> >
> > I was thinking of using "MemoryLayout.sequenceLayout(0, C_CHAR)" and
> > computing the
> > length at runtime, plus manually adding the null-terminator.
> >
> > Would this work alright, or is there some better way to do this?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221228/b185be40/attachment.htm>