osmocom
/
libosmocore
mirror of https://gerrit.osmocom.org/libosmocore
11
0
Fork 0
Code Issues Releases Wiki Activity

tell ubsan to ignore SUN_LEN 

ubsan will report undefined behavior due to the SUN_LEN macros interaction with a null pointer,
so let's tell ubsan to ignore this function. After carefully reviewing the final publically
availlable drafts of the C99,C11 and C18 standards I can confirm that dereferencing null pointers
is still undefined behavior, as such ubsan will always warn with absolutely every existing compiler
version. Since the sanitizers are periodically synced between llvm and gcc I'm also fairly confident
that rebuilding everything with compiler_rt to use the integrated sanitizers would result in the same message.
I sincerly hope that this explanation provides to be sufficient, If not I'd be willing to show up at
the next llvm dev meeting to provide quotes from actual sanitizer developers to back up these claims.

Change-Id: I0ff445072f1b46390c9f70b21d61c789e39358d5
This commit is contained in:
Eric Wild 2019-06-27 15:31:17 +02:00 committed by laforge
parent 1cc42f7b9e
commit eb5769b8b3
1 changed files with 3 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
src/socket.c
View File

@ -614,6 +614,9 @@ unsigned int osmo_sockaddr_to_str_and_uint(char *addr, unsigned int addr_len, ui
* type and \a proto and optionally binds or connects it, depending on
* the value of \a flags parameter.
*/
#if defined(__clang__) && defined(SUN_LEN)
__attribute__((no_sanitize("undefined")))
#endif
int osmo_sock_unix_init(uint16_t type, uint8_t proto,
const char *socket_path, unsigned int flags)
{