QuickJS, the Next Generation: a mighty JavaScript engine
b81d4deee4
String values are allocated as temporary or final results. This commit attempts to improve the consistency and performance of this step. - define `JS_NewString` as an inline function to allow simple expansion of `strlen()` for string literals - document string contents constraints regarding UTF-8 encoding. - rename `js_new_string8` as `js_new_string8_len`. takes `const char *`. - new inline function `js_new_string8` takes `const char *`, computes string length with `strlen` and calls `js_new_string8_len`. No overhead for string literals - rename `js_new_string16` to `js_new_string16_len` - use internal string allocation functions where appropriate, remove overhead - allocate extra byte for null terminator in source code string |
||
|---|---|---|
| .github/workflows | ||
| doc | ||
| examples | ||
| gen | ||
| test262@c1281dba45 | ||
| tests | ||
| .gitignore | ||
| .gitmodules | ||
| CMakeLists.txt | ||
| cutils.c | ||
| cutils.h | ||
| dirent_compat.h | ||
| getopt_compat.h | ||
| libbf.c | ||
| libbf.h | ||
| libregexp-opcode.h | ||
| libregexp.c | ||
| libregexp.h | ||
| libunicode-table.h | ||
| libunicode.c | ||
| libunicode.h | ||
| LICENSE | ||
| list.h | ||
| Makefile | ||
| qjs.c | ||
| qjsc.c | ||
| quickjs-atom.h | ||
| quickjs-c-atomics.h | ||
| quickjs-libc.c | ||
| quickjs-libc.h | ||
| quickjs-opcode.h | ||
| quickjs.c | ||
| quickjs.h | ||
| README.md | ||
| repl.js | ||
| run-test262.c | ||
| test262-fast.conf | ||
| test262.conf | ||
| test262_errors.txt | ||
| unicode_download.sh | ||
| unicode_gen.c | ||
| unicode_gen_def.h | ||
| v8-tweak.js | ||
| v8.js | ||
| v8.sh | ||
| v8.txt | ||
⚡️ QuickJS - A mighty JavaScript engine
Friendly QuickJS fork focused on reigniting the project.
Overview
In October 2023 @bnoordhuis and @saghul decided to fork the QuickJS project with the aim of reigniting it. They reached out to the original authors (@bellard and @chqrlie) about their intentions.
As of December 2023 the initial goal was somewhat accomplished. @bellard resumed working on the project and both parties have been pulling patches from each other since.
As of early 2024 both projects agree the proper path forward involves merging both projects and combining the efforts. While that may take a while, since both projects diverged in certain areas, there is willingness to go in this direction from both sides.