summaryrefslogtreecommitdiffstats
path: root/include/osmocom/coding/gsm0503_parity.h
diff options
context:
space:
mode:
authorNeels Hofmeyr <neels@hofmeyr.de>2018-12-05 21:32:21 +0100
committerNeels Hofmeyr <neels@hofmeyr.de>2018-12-10 13:18:38 +0100
commit496862818d2feabcac926a94a6be2d42826ab19f (patch)
treeab1ec9bbb019096500de5c1aedf5cc8cf300e986 /include/osmocom/coding/gsm0503_parity.h
parent2ca8cebac67cfa179af77aa8d507fd4b96b2b230 (diff)
gsm0408_test: test encoding and decoding Mobile Identity
One would think by now we would solidly encode and decode Mobile Identities. Well, guess again. - rc is sometimes the amount of bytes written, sometimes actual strlen(). - on string truncation, rc is sometimes strlen() (assuming nul terminated), and sometimes snprintf()-style would-be strlen(). - returned string, when truncated by not enough buffer size, is sometimes nul terminated, sometimes not. - gsm48_mi_to_string() happily reads a byte from zero-length input buffer. - gsm48_mi_to_string() happily writes to zero length output buffer. - gsm48_mi_to_string() returns nonempty string for empty input. - encoding a MI type that still has the GSM_MI_ODD flag set results in encoding an even-length MI as odd-length (hence appending a stray 'F'). I am going to tweak the implementation of gsm48 mobile identity encoding / decoding, so first pinpoint the current behavior in a unit test, and show how perforated even such a seemingly trivial API can be. Change-Id: Iaae3af87f82f1a8f2e6273984c011b2813038cf7
Diffstat (limited to 'include/osmocom/coding/gsm0503_parity.h')
0 files changed, 0 insertions, 0 deletions