gsm/{bsslap,bssmap_le}: zero-initialize structs using memset()

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

0 files changed, 0 insertions, 0 deletions