You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then if it encounters a value with the high bit set, this code in the generated C++ will be wrong:
voidkaitai_int_loop_t::_read() {
m_num_items = m__io->read_u4be();
m_items = new std::vector<uint8_t>();
constint l_items = num_items();
for (int i = 0; i < l_items; i++) {
m_items->push_back(m__io->read_u1());
}
m_next = m__io->read_u4be();
}
l_items will be typecast to a signed int, and will become negative. So the loop will be skipped (i always greater than l_items) and m_next will get the wrong value.
This is probably unlikely to be a major issue in practice, as it implies the file should be over 2GB in size even with u1 members. However, it does mean that the behaviour is not according to expectations or implied contract, in particular when the file is invalid. Rather than zooming off the end of the stream and throwing like it should, it can continue to read the file without any sign that it's parsing things in completely the wrong place. in this case, it will finish parsing happily and tell you next is bytes 0x04-0x08 in the file.
There's a small bug in the loop index variable in the C++ port relating to signedness of the variable.
If a
u4
is used as a loop variable:Then if it encounters a value with the high bit set, this code in the generated C++ will be wrong:
l_items
will be typecast to a signedint
, and will become negative. So the loop will be skipped (i
always greater thanl_items
) andm_next
will get the wrong value.This is probably unlikely to be a major issue in practice, as it implies the file should be over 2GB in size even with u1 members. However, it does mean that the behaviour is not according to expectations or implied contract, in particular when the file is invalid. Rather than zooming off the end of the stream and throwing like it should, it can continue to read the file without any sign that it's parsing things in completely the wrong place. in this case, it will finish parsing happily and tell you
next
is bytes 0x04-0x08 in the file.Please find attached a reproducing case:
archive.zip
Build, and run with
./kaitai_int_loop ../kaitai_int_loop.bin
. It should return 0, but it returns 1:Produes
The text was updated successfully, but these errors were encountered: