commit aa0683d9f8290515fb9c6681727beeba39a72c1e
author Vadim Yanitskiy <axilirator@gmail.com> Sat May 25 23:14:00 2019 +0700
committer Vadim Yanitskiy <axilirator@gmail.com> Tue May 28 06:50:41 2019 +0700
tree 90990138a9b42e97d034662e91230028f12ca8e2
parent 581a34da60abb4d1b5c32907961d7863a0ff3b8c

gsm0408/gsm0408_test.c: introduce BCD number encoding / decoding test

So far, both gsm48_encode_bcd_number() and gsm48_decode_bcd_number2()
did not have any unit test coverage. Let's fill this gap by testing
the following scenarios:

  - encoding / decoding of a regular 9-digit MSISDN;
  - encoding / decoding of a MSISDN with optional LHV;
  - encoding / decoding of a long 15-digit MSISDN;
  - encoding / decoding of a MSISDN to a buffer:
    - with exactly matching size,
    - with lower size (truncation);
  - decoding LV buffer with incorrect length,
  - encoding / decoding an empty input buffer.

As it turns out, gsm48_decode_bcd_number2() does not properly
handle encoded LV if the output buffer size is equal to the
original MSISDN length + 1 (\0-terminator): one digit is lost.

For example, decoding of 15-digit long MSISDN to a buffer of size
16 (15 digits + 1 for \0) would give us only 14 digits. This is
reflected in the unit test output:

  Decoding HEX (buffer limit=16) '0821436587092143f5'...
    Expected: (rc=0) '123456789012345'
      Actual: (rc=0) '12345678901234'

Moreover, if the output buffer is shorter than decoded number,
gsm48_decode_bcd_number2() silently truncates it and returns 0,
while its description states, that the rc should reflect this.

To be fixed in the follow-up patches.

Change-Id: I4b2c330cf8ffe4427c0bee7d5f3b74be56ecd85d
Related: OS#4025