On 3/14/24 10:16, Jose E. Marchesi wrote:
> 
> 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, added this to the commit message and pushed.

> 
> 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"

Reply via email to