When unknown APIs are used, the bytecode is skipped.
However we were still checking that the number of loaded functions is correct,
and of course we were failing because when skipping the number of loaded functions is
0. Fix this by not checking the number of loaded functions when skipping a
bytecode.
Do not reset filesize to 0.
Otherwise only the 1st bytecode executed in a hook can really scan the file,
all further bytecodes executed in same hook will fail to read anything from the
file.
Prevent 'Line too long for provided buffer'.
We must skip using a buffer of length declared in cbc header, not 4096.
So perform the skip in bytecode.c rather than readdb.c (which doesn't know the
length). The skip in readdb.c is good for skipping the source code, so keep it.
bytecode selfcheck running under JIT ran too early, and spawned a thread.
Then clamd forked. threads + fork = bad idea.
So prevent the thread from being spawned in selfcheck mode.
So at the time of fork clamd will still be single threaded as in 0.96.1.
Now you can call it both from a normal lsig triggered BC, and from a PE hook BC.
The normal lsig triggered BC has exe_info (but not PE info) which allows it to
invoke the icon matcher API.
Also putting ICONGROUP1 into the ldb trigger of the bytecode works.
pointers in the interpreter are of the form:
| pointer id | pointer offset |, where pointer id is an offset into an array
that contains information about the pointer like its bounds.
The last commits broke it: we store bytecode constants little-endian-like,
so an 8-bit constant is at offset 0, a 16-bit one at offsets 0,1; a 32-bit one
at 0,1,2,3; and a 64-bit one 0,1,2,3,4,5,6,7,8.
Of course the constant itself is in host-endianness.
It was not computing the size of structs.
Bug: all bytecodes that had structs on the stack failed with internal
out-of-bounds errors.
Workaround: compiler will need to avoid putting structs on stack, or do so only
for FLEVEL == 0.96.2
