rz_asm_tokenize_asm_string() can return NULL for example if the given
string is empty, so this has to be caught.
In rz_asm_colorize_asm_str(), we could fallback to returning an empty
string, but since this function allocates on the heap, it may return
NULL in any case, so we have to adjust all of its callers anyway and
that means we can just pass the NULL from rz_asm_tokenize_asm_string().
`rz -Qc 'pd 2 @e:asm.pseudo=1' test/bins/elf/mipsloop` shows the initial
issue.
Tests and extends deriving paths into types at a given offset in the
following ways:
- Parameter for limiting the depth of the path
- Array support, e.g. `.member[5].anothermember`
- Typedef support
- Paths can be taken from arbitrary RzTypes, not only RzBaseType
- Removed the typename in the beginning of paths, which can be added by
the caller if needed
Even if the case is nonsensical in practice, we can't rule out the
possibility that the reference chain induced by a typedef may not
contain a loop, which could lead to infinite recursion when trying to
infer the actual underlying type.
Previously only the case where a typedef points to itself directly was
handled, but loops in multiple steps are possible too. So we introduce
rz_type_db_base_type_unwrap_typedef(), which handles the full
(multi-step) loop-aware unwrapping in one place and use it wherever
needed.
* Fix Coverity issue 403157
* Out of bounds check should also check for equality
* Add `port_label` in `rz_x86_il_config`
* Fix typo while parsing register in x86 assembler
* Check return type `getToken` when parsing registers in x86 assembler
if the dynamic section's verneednum mismatches the true number of entries then the for loop in get_gnu_verneed will continue to iterate on the last entry since vn_next will be 0 on the last entry. If verneednum is set to all 0xff's it will take a very long time to finish this loop naturally drastically hindering binary load time. The solution is simple, to check for when vn_next == 0 and break out of the loop since all entries have been iterated over regardless of what verneednum indicates.
Even though many of the migrations were trivial, for all previous
versions X it is important to have both tests for X->X+1 migrations
and loading X in current rizin.
See leading comment in test_project_migrate.c for details.
Leaks detected by these tests were also fixed.
