[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bruno Haible
Subject: Re: uninorm/composition.c:75:22: runtime error
Date: Fri, 04 Mar 2022 14:21:06 +0100

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 
$ ./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, 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior foo.c:5:21 in 

But what exactly is undefined behaviour here? 
According to ISO C 2018 § and §, 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'?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]