|
|
|
|
|
|
by flohofwoe
96 days ago
|
|
|
...all way too high level for my taste and those problems are not WASM specific yet still have been solved outside WASM via operating-system/platform ABI conventions which compilers and 'user code' has to adhere to without requiring a 'component model'. Some operating systems might want their strings as UTF-8 encoded, some as UTF-16. It's the job of the caller to provide the strings in the right format before calling the OS function. In the end it's up to the caller and callee to agree on a format for string data. There is no 'middleman' or canonical standard format needed, just an agreement between a specific caller and callee. The good and important part of such an agreement is that it is unopinionated. As long as caller and callee agree, it's totally fine to pass zero-terminated bytes, other callers and callees might find a pointer/size pair better. This sort of agreement also needs to happen when calling between native Rust and C code (or calling between any language for that matter). My C code might even prefer to receive string data as pointer/size pairs instead of zero-terminated bytes when all my string-processing code is built on top of strings as pointer/size pairs (e.g. apart from string literals there is not a single feature in the C language which dictates that strings are zero-terminated bags of bytes - it's mostly just of convention of the ancient C stdlib functions). IMHO the WASM Component Model is solving a problem that just isn't all that relevant in practice. System ABIs / calling conventions don't need a 'component model' and so shouldn't WASM. |
|
|
But for the other 99% of devs who just want to exchange strings across various language boundaries without quadratic glue complexity, we have the CM.