[foreign-memaccess+abi] RFR: 8308858: FFM API and strings [v2]

[Jorn Vernee]

On Wed, 7 Jun 2023 15:34:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I guess an alternate design would be to ask the user how many terminator chars there should be (where that has to be a power of two). Then we could allow any charsets, including non-sensical ones. Something like:
> 
> ```
> getString(long offset) // shortcut for getString(offset, defaultCharset(), 1);
> getString(long offset, Charset charset, int numTermChars)
> 
> setString(long offset, String string) // shortcut for setString(offset, defaultCharset(), 1, string);
> setString(long offset, Charset charset, int numTermChars, String string)
> ```

For `getString` we need to determine the length of the string. And I think for `setString` we need to determine how many 0 bytes we need to put at the end? Really, those are the crucial elements, since the rest is just a bulk copy.

Maybe for getString we could just explicitly ask the user for the size of the string? (excluding the terminator). That way we don't need to manually determine the string length. For users that means there is still a convenient wrapper that does the decoding and bulk copy. That would also work for loading sub strings, where there is no null terminator directly after the native string, which might be nice.

I suppose to `setString` we could also just use "\0".getBytes(charset), and then append that to the end of the native string, but as you said before, a charset encoder might add some arbitrary trailing bytes at the end of the string, so I'm not sure if this will work. And there might be issues with meta bytes, such as the BOM in UTF16. So, I think just knowing the number of terminator chars isn't enough to make this work... And again, I feel like Charset is just not suited for handling native strings out of the box (though we can to special case some of them).

-------------

PR Comment: https://git.openjdk.org/panama-foreign/pull/836#issuecomment-1581115507