Simple program I made when I was experimenting with inttypes.h:
#include <stdio.h>
#include <stdbool.h>
#include <inttypes.h>
bool get_bit(uint32_t x, uint8_t n) {
x >>= n;
return x & 1;
}
int main() {
uint32_t x;
uint8_t n;
printf ("Enter x: ");
scanf("%"SCNu32, &x);
printf ("Enter n: ");
scanf("%"SCNu8, &n);
printf("The %"PRIu8"th bit of %"PRIu32" is: %d", n, x, get_bit(x, n));
return 0;
}
On my phone (64 bit octa core ARN LTE Soc Android 10) it works fine:
Enter x: 1
Enter n: 0
The 0th bit of 1 is: 1
But on my computer (64 bit x86 Windows 10) I get:
Enter x: 1
Enter n: 0
The 0th bit of 0 is: 0
Changing bool to uint8_t doesn't affect it.
EDIT: I tried compiling with MinGW-w64 GCC C99 and C17.
It seems you might get this problem in case you are using a Windows compiler which uses Microsoft's non-compliant CRT (non)standard library. That is: Visual Studio or Mingw64/gcc.
I can reproduce it on Mingw/gcc. It's a well-known problem that the Microsoft CRT is broken and for example doesn't support various format specifiers introduced in C99. It would seem that the problem lies in scanf reading with the wrong format specifier, because when compiling with all warnings enabled, I get:
warning: unknown conversion type character 'h' in format [-Wformat=]
%hh being what sits underneath the hood of SCNu8 but the compiler only reads as far as %h and stops there. The scanf call actually fails.
You can uncrap the CRT lib at least in Mingw by using the following:
#define __USE_MINGW_ANSI_STDIO 1
#include <stdio.h>
When I added the above to your code, I get The 0th bit of 1 is: 1.
Without the above patch it I get The 0th bit of 0 is: 0