Not sure if this was a typo or not, but seems like might be given that the integer wouldn't fit into a u32. If this is not a typo and was intentional, I'd be interested to understand the reasoning behind it.
Even if this is a typo, it does not appear to have any visible impact on the behavior. At least on my compiler (Clang, macOS), the UINT32_C macro applied to integers that are too large to fit in 32 bits still seems to produce values of type unsigned long, which is 64 bits on my compiler. I don't know if there are other compilers where this indeed results in a bug.
Not sure if this was a typo or not, but seems like might be given that the integer wouldn't fit into a
u32
. If this is not a typo and was intentional, I'd be interested to understand the reasoning behind it.Even if this is a typo, it does not appear to have any visible impact on the behavior. At least on my compiler (Clang, macOS), the UINT32_C macro applied to integers that are too large to fit in 32 bits still seems to produce values of type
unsigned long
, which is 64 bits on my compiler. I don't know if there are other compilers where this indeed results in a bug.