Deserialized bytecode does not have IC state, i.e., `bc->ic == NULL`.
That may or may not be bug (IMO, it is and we should rebuild the
IC state during deserialization) but, either way, don't segfault.
DRY add_ic_slot() and its call sites in a hopefully NFC manner.
Don't raise a "invalid tag 12" exception when encountering bytecode
and JS_READ_OBJ_BYTECODE is not set, because no one knows what "tag 12"
means without looking it up, not even quickjs maintainers.
Otherwise it's too easy to tie up too many resources (cpu, memory) by
crafting inputs with a very large atom count (up to 4 billion.)
This may need some finetuning. If the limit proves too restrictive for
very large snapshots, we can make it relative to the size of the input.
Check inside the deserializer that const atoms are indeed const, don't
trust the input. The serializer only writes type 0 records for const
atoms but the byte stream may have been corrupted or manipulated.
Overlooked during review of c25aad7 ("Add ability to (de)serialize
symbols")
Found with libfuzzer and it found it _really_ fast. Great tool.
I find it convenient to have access to JS_ReadObject and JS_WriteObject
from JS land. That's precisely the functionality that tests/bjson.c
provides, ergo, move it into quickjs-libc.c
* Improve `Date.parse()`
- rewrite `Date.parse()` with separate parsers
- return `NaN` for out of bounds field values as specified
- add `js_tzabbr` and `string_get_tzabbr` to handle timezone abbreviations
- improve `string_get_milliseconds` readability
- accept up to 9 decimals for millisecond fraction but truncate at 3
- accept many more alternative date/time formats
- add test cases in **tests/test_builtin.js**
- produce readable output for `Date` objects in repl
- use `JSON.stringify` to output `Date` and `string` values in **repl.js**
- remove `String.prototype.__quote`
- add `minimum_length` macro to specify argument array sizes (C99 except MSVC)
- v8.js: parse all environment variables and output them, update **v8.txt**
