Featture: expose stringToBuffer in ffi#739
Conversation
src/mod_ffi.c
Outdated
| size_t len = 0; | ||
| const char *ptr = JS_ToCStringLen(ctx, &len, argv[0]); | ||
|
|
||
| return JS_NewUint8Array(ctx, ptr, len, NULL, NULL, false); |
There was a problem hiding this comment.
You probably want to use TJS_NewUint8Array here, because otherwise you'll leak the ptr as there is no free function passed.
There was a problem hiding this comment.
indeed. Thank you. I am still trying to get my bearings in the codebase :)
|
Cheers! |
There is a PR #700 |
@lal12, can you push some small change so CI can recheck. Some windows build is failing and the logs have expired. Also would you be okay if I suggest some cosmetic changes? I reviewed the code with my limited c experience and find couple of functions hard to read due to missing defines/constants in returns. I can add some comments to the PR if you are okay with that. P.S. I am by no means experienced in c/c++ or affiliated with this project :) |
|
@ldeninski I rebased the PR. So let's see if it goes through the CI... Btw. I tried to follow the specs pseudo code as closely as possible, so hopefully spec compliant, but not the most efficient way. Also it has significant overhead, because of QucikJS internals (see #447) |
This PR exposes a stringToBuffer function that is the inverse of bufferToString. This is useful for writing utf-8 encoded strings to sockets. It is intended to be used along with the changes in KawaiiZapic/h3-txikijs-adapter#1
A logical next step would be to implement a proper TextEncoder and TextDecoder that are using these functions as the js polyfills are really inefficient.
P.S. I will try to make the time for a proper decoder and encoder implementation if the maintainers are okay with that.