3 ms·

Here's a mini-quiz: on a regular gcc/clang for x86/x86-64/arm32/arm64, which of the following functions can ever produce undefined behavior? Answers can be obta

by dzaima 3y ago

Here's a mini-quiz: on a regular gcc/clang for x86/x86-64/arm32/arm64, which of the following functions can ever produce undefined behavior? Answers can be obtained by compiling with "-O3 -fsanitize=undefined" and seeing which functions include __ubsan_handle*. int16_t a( int16_t a, int16_t b) { return a*b; } uint16_t b(uint16_t a, uint16_t b) { return a*b; } int32_t c( int32_t a, int32_t b) { return a*b; } uint32_t d(uint32_t a, uint32_t b) { return a*b; }

deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
ryao 3y ago
For 32-bit types, the undefined behavior is where I expected it to be, but it is the opposite for the 16-bit types. Why are the 16-bit types different? To make things weirder, I tried 8-bit and 64-bit versions. The 64-bit version behaved like the 32-bit versions, but the 8-bit versions had no undefined behavior checks. Why is 8-bit so different?
- dzaima 3y ago
  Smaller-than-'int' types get implicitly promoted to 'int' before arithmetic. Results are indeed very funky.
  - ryao 3y ago
    That makes sense then. Multiplying two uint16_t can wraparound in an int, while two int16_t or smaller cannot.