diff options
author | Stefan Sperling <ssperling@sysmocom.de> | 2018-03-15 18:05:02 +0100 |
---|---|---|
committer | Stefan Sperling <ssperling@sysmocom.de> | 2018-03-15 18:27:30 +0100 |
commit | e1a86748a2c7f6154644deee0477f629a86ca8ec (patch) | |
tree | 30a68874708b27619b06a3e088a3bf584dc217b4 /tests/tlv/tlv_test.c | |
parent | 2873bf1f331dc07e6c92b4f6a0b45f26683a0f0b (diff) |
fix cell identifier decoding in libosmocore
The cell ID list decoder merged in 11a4d9dd91216fe353e94bfdbbab53bc4f891c0d
has a bug which was introduced part-way through the review process in
gerrit at https://gerrit.osmocom.org/#/c/6509/
When Neels suggested "why not just {...}id_list[MAXLEN] once?" I changed
the cell identifier list from a union of arrays to an array of unions.
After this change, elements smaller than the largest type in the union
were not laid out consecutively in memory anymore. E.g. uint16_t lac
values now occur at offsets of sizeof(id_list[0]) instead of offsets
of sizeof(uint16_t).
The problem is that I forgot to adjust the decoder accordingly, so the
decoder writes to the wrong offsets and returns cell identifier lists
which appear to contain uninitialized values when read back by API
consumers.
I found this problem while adding new regression tests to libosmocore to
test encoding and decoding. This commit adds one such tests for LAC list
decoding, which failed due to the above bug. I plan to write more tests,
however because this first test already uncovered a severe issue I chose
to submit a fix now and work on additional tests in later commits.
Change-Id: Ie1a5a9d858226be578cf11a03cf996d509bd51fb
Related: OS#2847
Diffstat (limited to 'tests/tlv/tlv_test.c')
0 files changed, 0 insertions, 0 deletions