<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<div class="moz-cite-prefix">On 26/3/23 23:16, Maurizio Cimadamore
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a24f7f61-9e1f-5a14-8777-c38e449cd502@oracle.com">Forgot:
another problem is that just offloading to external "strlen"
will not respect the memory segment boundaries (e.g. the
underlying strlen will keep going even past the spatial
boundaries of the memory segment).
</blockquote>
<br>
But it'll be a very common case that the strings are from
unbounded pointers such as query methods that return a pointer or
struct members of char *. For such memorysegments it would be an
obvious fit. But I suppose if it's actually a problem for anyone
they just can roll their own implementation.<br>
<br>
On 26/3/23 22:52, Maurizio Cimadamore wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c2144f1b-b9ba-3a6a-ee69-59b6d7fa0a4c@oracle.com">I think
allowing easier creation of struct layouts (as I stated in the
other email) is a nice to have. The main question is to whether
the API should allow for creation of layouts that are "bad" or
not. For most use cases, I agree that the preferred answer would
be "no" - I wonder if in most advanced cases where a client wants
to transform an existing struct layout into a new one, not having
the ability to say where padding should go will backfire.
</blockquote>
<br>
I'd be curious to know what these "advanced cases" could possibly
be? And how an object ostensibly for creating varhandles that can't
create varhandles could have any practical use? Alignment is
enforced everywhere else, it seems so arbitrarily inconsistent not
to do so here.<br>
<br>
As far as I can tell anything you can actually do in c you could
also do with a layout api that enforced the alignment (and
calculated the post-struct padding) based on the layout details of
the members. And explicit padding layouts could still be used to
add arbitrary gaps.<br>
<br>
e.g.<br>
<font face="monospace">struct __attribute__((packed)) a {<br>
</font><font face="monospace"><font face="monospace"> char b;<br>
</font> int a;<br>
}<br>
sizeof == 5<br>
===<br>
structLayout(</font><font face="monospace"><font face="monospace">JAVA_BYTE.withName("a"),
</font><b>JAVA_INT_UNALIGNED</b>.withName("b"));<br>
</font><br>
<br>
<font face="monospace">struct __attribute__((packed)) a {<br>
</font><font face="monospace"><font face="monospace"> char b;<br>
</font> int a __attribute__((aligned(2)));<br>
}<br>
size == 6<br>
===<br>
structLayout(</font><font face="monospace"><font face="monospace">JAVA_BYTE.withName("a"),
</font>JAVA_INT.<b>withBitAlignment(16).</b>withName("b")); //
assuming enforced padding<br>
</font><font face="monospace"><font face="monospace"><br>
</font><br>
</font>It's not rocket science - you can only tweak the packing in
one way, by changing alignment by (2^N) bytes. C just doesn't have
support for creating arbitrary bitstreams using struct or union -
for anything like that you're forced to do it by hand with something
like a ByteBuffer. If you wanted to translate to or from a packed
to non-packed actual 'struct' you'd just use two separate struct
definitions and copy them member by member - and you'd have to do
the same with MemoryLayout.<br>
<br>
I came across an article about the practicalities of the struct
packing rules - it's mostly based on what maps efficiently to real
hardware[1]. Micrsoft's struct layout is basically the same as
gcc[2] apart from bitfields, but they're never portable anyway.<br>
<br>
Maybe some obscure compilers have other facilities for special
purposes as they are beyond the c standard. But this also means the
system ABI is usually used for struct packing for re-usable
libraries, that's sort of the whole point of having a system ABI
defined - particularly for exactly the case of multi-language
inter-op that the foreign abi is for.<br>
<br>
"maybe it could be useful to someone some time" sounds a lot like
over engineering to me. Apparently also more specifically called
"Boat Anchor" "anti-pattern" these days [3].<br>
<br>
Anyway i've said my piece for now and i'll go back to lurking.<br>
<br>
Z<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://www.catb.org/esr/structure-packing/">http://www.catb.org/esr/structure-packing/</a><br>
[2]
<a class="moz-txt-link-freetext" href="https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mms-bitfields">https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mms-bitfields</a><br>
[3] <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Boat_anchor_(metaphor)#Software">https://en.wikipedia.org/wiki/Boat_anchor_(metaphor)#Software</a><br>
<br>
</body>
</html>