UBSan complains when doing left shift for some inputs

[aap-sc]

Build:

CFLAGS="-fsanitize=undefined -Wl,-ldl" ./configure 
make

Run jimsh:

./jimsh
expr { 1 << 63 }
# UBSan complains - jim.c:8563:25: runtime error: left shift of 1 by 63 places cannot be represented in type 'long long int'

Another issue is that interpreter allows for inputs such as these:

expr { -1 << 1 } ; # UBSan complains - left shift of negative value -1
expr { 1 << -3 } ; # UB San complains - runtime error: shift exponent -3 is negative

Technically, some of these cases can be considered as incorrect user input, since jimtcl operates on signed integers internally. Still, interpreter allows for such inputs...

1. Maybe it could be worth to add diagnostics to get rid of incorrect inputs?
2. For cases which are "almost legal", like { 1 << 63 } one could detect that both operands are non-negative and perform operation on unsigned type, converting the result back to signed (leading to implementation-defined behavior till C23)

To be fair all this may be an overkill. However, fixing this may simplify sanitize-based checks for applications that embed jimtcl.

[msteveb]

I'm not inclined to implement this. It's a run time, not a compile time cost that is incurred by everyone for a very, very small number of potential situations. That's like running ubsan every time, instead of only during testing. What do you want to do in undefined behaviour cases? Throw an error? Perhaps it could be a configurable compile time option, but someone else will need to implement it. Perhaps some of the simpler cases are easy enough like shifting by a negative number, overflow checking of addition, multiplication and negation seem harder

[aap-sc]

I'm not inclined to implement this.

I see. That's understandable.

What do you want to do in undefined behaviour cases? Throw an error?

Well, yeah.. That was an idea I had in mind.

Perhaps it could be a configurable compile time option, but someone else will need to implement it. Perhaps some of the simpler cases are easy enough

So basically you are not against patches that may address this right?

Perhaps some of the simpler cases are easy enough like shifting by a negative number,

I personally interested in improving this in context of OpenOCD tasks. For example it seems reasonable that operations like 1 << 63 to behave without ubsan reporting a potential UB. I can try to provide patches for the detected "simple" cases, if there is no strong push back.

[msteveb]

Yes, completely open to patches that are not detrimental (e.g. performance) to most users, or if so, then it is a configuration-time setting that can be turned off as required.