Link error when compiling with -fsanitize=undefined

[Jean-Marc Lasgouttes]

Le 21/09/2021 à 16:52, Scott Kostyshak a écrit :
>> Some debugging lead to following observation:
>> Each inserted branch add a color to the list. The original enum defined colors (about
>> 102), last Color_ignore.
>> So each branch will now get colors 103, 104, ..., and so on, so that the original enum
>> (probably used as 'char') cannot contain the value beyond 127).
>>
>> Expanding the colors in src/ColorCode.h as in attached, removes the sanitize messages.
> 
> Nice, that makes sense. 500 seems to be a reasonable ceiling. I suppose an alternative would be to have the code stop assigning new colors past the max. That is, I imagine they could just assign the max color value to multiple insets?

But why the 127? Is it that the underlying type of the enum is a signed 
char? What does sizeof(ColorCode) return?

If this is the case, using
   enum ColorCode : int {
should help. But I am surprised because the underlying type should be 
int (unless -fshort-enums is used):
https://stackoverflow.com/questions/1122096/what-is-the-underlying-type-of-a-c-enum

> I didn't understand how JMarc's suggestion to change the type to int would solve the (non) issue.

I was under the impression that the code would check that the enum value 
was one of the declared values. But this is not the case, since a number 
of synthetic values between 100 and 127 seem to be valid.

I also wonder how you triggered it initially. Is it that you really had 
25+ branches, or is it that the code "leaks" color code and creates too 
many of them?

JMarc