Re: uninorm/composition.c:75:22: runtime error

[Bruno Haible]

Simon Josefsson wrote:
> The uninorm/composition.c code looks like this:
> 
> ucs4_t
> uc_composition (ucs4_t uc1, ucs4_t uc2)
> {
> ...
>           char codes[6];
> ...
>           codes[2] = uc1 & 0xff;

I could rewrite this line as

            codes[2] = (char) (unsigned char) (uc1 & 0xff);

but this would be adding redundant casts, which - as Paul often remarks -
hamper maintainability.

> with ASAN/UBSAN checks [2]

You use the clang options
'-fsanitize=undefined,integer -fno-sanitize-recover=undefined,integer'.

I reproduce the issue with clang 13:

$ cat foo.c
#include <stdio.h>
int main ()
{
  volatile unsigned char x = 218;
  volatile char y = x;
  return 0;
}

$ clang -fsanitize=undefined,integer -fno-sanitize-recover=undefined,integer 
foo.c
$ ./a.out 
foo.c:5:21: runtime error: implicit conversion from type 'unsigned char' of 
value 218 (8-bit, unsigned) to type 'char' changed the value to -38 (8-bit, 
signed)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior foo.c:5:21 in 

But what exactly is undefined behaviour here? 
According to ISO C 2018 § 6.5.16.1.(2) and § 6.3.1.3.(3), assigning 218
to a 'signed char' is implementation-defined.

Adding a cast to 'char' silences the UBSAN:
  volatile char y = (char) x;

Paul, do you agree that it's a good idea to add an explicit cast, to avoid
implicit conversion from 'unsigned char' to 'char'?

Bruno