In the unit tests we're using memcmp() to compare decoding results
against the expected results. This is a reasonable approach, but
there is a pitfall: not only the struct fields are compared, but
also the padding bytes preceding/following them.
When using gcc's extension zero-initializer {} or even the standard
approved { 0 } zero-initializer, padding bytes are not guaranteed
to be zeroed. Even worse, according to [1], the init behavior is
inconsistent between gcc and clang and optimization levels.
All decoding functions in {bsslap,bssmap_le}.c currently use gcc's
extension zero-initializer {}. This is not a problem when building
with CC=gcc, but with CC=clang the bssmap_le_test fails due to
mismatch of padding bytes in struct lcs_cause_ie:
[4] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU
[5] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU
[6] PERFORM LOCATION ABORT: ERROR: decoded PDU != encoded PDU
Out of the known struct initialization methods, only the memset()
has consistent behavior and sets all bytes to zero, including the
padding ones. Using it fixes the bssmap_le_test for CC=clang.
[1] https://interrupt.memfault.com/blog/c-struct-padding-initialization
Change-Id: Ib16964b16eb04315efc416164ed46c15b5dc7254
Fixes: OS#5923
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I5050285e75cf120407a1d883e99b3c4bcae8ffd7
BSSLAP: there are APDUs transferred in BSSMAP-LE Connection Oriented
Information messages on Lb between BSC and SMLC.
Add BSSLAP coding for these APDU messages:
- TA Layer3
- TA Request
- TA Response, possibly containing Location Estimate coded in GAD
- Reject
- Reset (for intra-BSS handover during TA Request)
- Abort (for inter-BSS handover)
Add encoding and decoding tests.
Change-Id: I6409c4bcac402dc7626a3afce9081c59cd715fe8