Tim Rühsen reports:
> configure:14038: checking for working C stack overflow detection
> SUMMARY: UndefinedBehaviorSanitizer: implicit-integer-sign-change
Here's a reduced test case:
$ cat foo.c
#include <signal.h>
int
main ()
{
struct sigaction act;
act.sa_flags = /* SA_NODEFER | SA_ONSTACK | */ SA_RESETHAND;
return 0;
}
$ clang -Wall foo.c -E | grep sa_flags
int sa_flags;
act.sa_flags = 0x80000000;
$ clang -Wall foo.c -fsanitize=implicit-integer-sign-change
$ ./a.out
foo.c:7:50: runtime error: implicit conversion from type 'unsigned int' of
value 2147483648 (32-bit, unsigned) to type 'int' changed the value to
-2147483648 (32-bit, signed)
So, glibc defines the 'sa_flags' field as being of type 'int' (like
POSIX [1] mandates). glibc also defines SA_RESETHAND as 0x80000000.
The compiler interprets this constant as being of type 'unsigned int'.
The sanitizer then complains about an implicit conversion from 'unsigned int'
to 'int'.
How to resolve this?
- Should glibc define SA_RESETHAND as ((int)0x80000000) ?
Then SA_RESETHAND could not be used in preprocessor directives any more.
- Should clang be silent about this case of implicit conversion?
- Should we discourage users from using -fsanitize=implicit-integer-sign-change?
Bruno
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html
