Hi David.
> Change the BPF backend to define INT8_TYPE with an explicit sign, rather > than a plain char. This is in line with other targets and removes the > risk of int8_t being affected by the signedness of the plain char type > of the host system. OK. I would add to the commit message that the motivation for this change is that even if `char' is defined to be signed in BPF targets, some BPF programs use the (mal)practice of including internal libc headers indirectly via kernel headers and that may trigger compilation errors regarding redefinitions of types. Thanks for the patch! > > Tested on x86_64-linux-gnu host for bpf-unknown-none. > Sanity checked compiling Linux kernel BPF selftests. > > gcc/ > > * config/bpf/bpf.h (INT8_TYPE): Change to signed char. > --- > gcc/config/bpf/bpf.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/config/bpf/bpf.h b/gcc/config/bpf/bpf.h > index f107a5a4c34..3cc5daa1b58 100644 > --- a/gcc/config/bpf/bpf.h > +++ b/gcc/config/bpf/bpf.h > @@ -99,7 +99,7 @@ > > #define SIG_ATOMIC_TYPE "char" > > -#define INT8_TYPE "char" > +#define INT8_TYPE "signed char" > #define INT16_TYPE "short int" > #define INT32_TYPE "int" > #define INT64_TYPE "long int"
