Re: [PATCH 1/2] gdb: testsuite: fix failed testcases in gdb.base/charset.exp

[Tiezhu Yang <yangtiezhu@loongson.cn>]

On 1/10/22 10:42, Simon Marchi wrote:
> 
> 
> On 2021-12-24 23:03, Tiezhu Yang wrote:
>> In gdb/testsuite/gdb.base/charset.c, the last argument is greater than 127
>> when call fill_run() in EBCDIC-US and IBM1047, but the type of string[] is
>> char, this will change the value due to sign extension.
>>
>> For example, ebcdic_us_string[7] will be -63 instead of the original 193 in
>> EBCDIC-US.
>>
>> Make the type of string[] as unsigned char to fix the following six failed
>> testcases:
>>
>>    $ grep FAIL gdb/testsuite/gdb.sum
>>    FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US
>>    FAIL: gdb.base/charset.exp: check value of parsed string literal in EBCDIC-US
>>    FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in EBCDIC-US
>>    FAIL: gdb.base/charset.exp: check value of parsed character literal in IBM1047
>>    FAIL: gdb.base/charset.exp: check value of parsed string literal in IBM1047
>>    FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in IBM1047
> 
> Out of curiosity, on which configuration do you see these failures?

I test this on LoongArch which is a new RISC architecture.

> Asking because I don't see them on x86-64 Linux.
> 
> Is it related to the fact that some architectures have "char" signed by
> default and others unsigned by default?

Yes.

Each kind of machine has a default for what char should be. It is either 
like unsigned char by default or like signed char by default.

Ideally, a portable program should always use signed char or unsigned 
char when it depends on the signedness of an object.

https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

Thanks,
Tiezhu

> 
> Simon