readme: add known issues

Author: ligurio

README.md

@@ -66,6 +66,36 @@ cd build && RUNS=100000 ctest -R luaL_gsub_test --verbose
 - [Lua 5.2 Reference Manual: 4 – The Application Program Interface](https://www.lua.org/manual/5.2/manual.html#4)
 - [Lua 5.1 Reference Manual: 3 – The Application Program Interface](https://www.lua.org/manual/5.1/manual.html#3)
 
+### Known Issues
+
+Fuzzing can find a wide variety of problems, but not all problems
+are considered bugs. Some problems are due to known limitations in
+the implementation. This section contains a list of such
+limitations in LuaJIT and PUC Rio Lua:
+
+1. LuaJIT build infrastructure has source code that contains
+   memory leaks and other problems. For example,
+   `src/host/buildvm.c` and `src/host/minilua.c`. Suppressed in
+   AddressSanitizer with function `__lsan_is_turned_off()` that
+   disallow leak checking for the program it is linked into.
+1. Bytecode input is unsafe in LuaJIT, see
+   https://github.com/LuaJIT/LuaJIT/issues/847 and https://luajit.org/faq.html#sandbox.
+   The string "mode" controls whether the chunk can be text or binary
+   (that is, a precompiled chunk). It may be the string "b" (only binary
+   chunks), "t" (only text chunks), or "bt" (both binary and text). The
+   default is "bt". Lua runtime (at least PUC Rio Lua and LuaJIT)
+   has bytecode and Lua parsers. It is desired to test both
+   parsers, however, in LuaJIT bytecode parser failed with assertion:
+   LuaJIT ASSERT `lj_bcread.c:123: bcread_byte: buffer read overflow`
+   so in LuaJIT only text mode is used and therefore only text parser is
+   tested.
+1. The `debug` library is defined as unsafe. There are tons of ways
+   to produce a crash with it. See https://github.com/LuaJIT/LuaJIT/issues/1264.
+   The `debug` functions is not a subject of testing.
+1. String functions `lj_str_new()` and `lj_str_cmp()` may read
+   pass a buffer end (so called "dirty" read). Suppressed in
+   AddressSanitizer with `__attribute__((no_sanitize_address))`.
+
 ### License
 
 Copyright (C) 2022-2025 [Sergey Bronnikov](https://bronevichok.ru/),