Despite it was stated that only the last nibble isn't being
written, some other bytes in the middle of the output buffer
were uninitialized during the first exectution of a queue.
The problem was observed with AddressSanitizer enabled.
Valgrind output:
$ valgrind --track-origins=yes \
src/.libs/lt-osmo-gapk \
-i tests/ref-files/hhgttg_part1_5.s16.ti-efr \
-f ti-efr -g rawpcm-s16le \
-o /dev/null -v
Conditional jump or move depends on uninitialised value(s)
at 0x52728F2: msb_put_bit (utils.h:39)
by 0x52728F2: amr_efr_from_canon (fmt_amr.c:45)
by 0x5270A7D: osmo_gapk_pq_execute (procqueue.c:202)
by 0x40296A: run (app_osmo_gapk.c:650)
by 0x40296A: main (app_osmo_gapk.c:778)
Uninitialised value was created by a heap allocation
at 0x4C2AB80: malloc (in vgpreload_memcheck-amd64-linux.so)
by 0x4E3C2A8: talloc_named_const (in libtalloc.so.2.1.5)
by 0x5270A1B: osmo_gapk_pq_prepare (procqueue.c:180)
by 0x402940: run (app_osmo_gapk.c:645)
by 0x402940: main (app_osmo_gapk.c:778)
Change-Id: I79df56dde23702b0eac8e8fdbc0efd270cc0ace4
Related: OS#2934
To avoid a naming conflict between libosmogapk and other projects
during linkage, all the exposed symbols should have an unique
prefix. Let's use 'osmo_gapk' for that.
To be able to use the library, external applications need to know,
which symbols are exposed. This information is provided by header
files, which are being installed to a system's ${includedir}
since this change.
I noticed that ti-hr format doesn't pass an encode-decode-playback test,
and discussion with tnt resulted in the following conclusion:
19:29 <@tnt> looking at fr and efr, it's always msb_xxx
19:30 <@tnt> and if I ever used it, then most likely it was for decoding
meaning ti_hr_to_canon would have been used and not the
other way around.
Vadim Yanitskiy
Harald Welte
Sylvain Munaut