Closed ievenbach closed 4 months ago
I am not sure that this is right. n & 0x3ff
is a positive signed integer of at most 0x3ff. If you shift that signed value by 22 bits to the left, then the value can become negative, which is again undefined behavior. I think, this would require at least n & 0x3ffu
.
I think the problem here is that shifting a u16 value by 22 is undefined behavior. If so, a better fix is ((uint32_t) n) << 22)
.
Does that also avoid the ubsan issue?
OK. You are right. I simply changed data type of n, and it worked. Is there a good reason for n to still be uint16_t?
merged. Thank you!!
The value of "n" used to calculate get the unique port within application is 10 bit. This change applies corresponding mask to n, prior to left-shifting it.