commit 7b9b3074a282ba5f38476993dcb47e5fc7e77223
author Vadim Yanitskiy <vyanitskiy@sysmocom.de> Sat Feb 25 05:52:37 2023 +0700
committer laforge <laforge@osmocom.org> Sat Feb 25 08:15:11 2023 +0000
tree 0feefbc266d124ee34b7311b7083e20a7ae84589
parent 6b69b554f7622c7025ce620486c0bda9b0db8f4a

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