> The unsigned long type has an implementation-defined width...
That's true, but well, it's not doing a left shift but a right shift. For left shifts, you'd usually write something like (c << 8) & 0xFFFFFFFF, or just use a fixed-width type (as you say).
> Oops, wait, no there isn't; it's only required to be there if the platform has a 32 bit type.
Most languages just have the standard integer size be 32 bits, and pretty much all machines/compilers today have uint32_t. If you just make uint32_t a requirement you get basically what you get in these other languages. Alternatively stick with (unsigned) int/long/long long, possibly wrapped in a typedef. I don't see what's the problem here. Plenty of options, pick your portability / explicitness tradeoff.
> You can easily find C code in the wild written in two (or more ) ways. Search almost any project for #if and #ifdef.
Sure, but not for this regular kind of bit-shoveling code. Mostly for platform integration. And yes, a little bit of setup code to support different compilers.
That's true, but well, it's not doing a left shift but a right shift. For left shifts, you'd usually write something like (c << 8) & 0xFFFFFFFF, or just use a fixed-width type (as you say).
> Oops, wait, no there isn't; it's only required to be there if the platform has a 32 bit type.
Most languages just have the standard integer size be 32 bits, and pretty much all machines/compilers today have uint32_t. If you just make uint32_t a requirement you get basically what you get in these other languages. Alternatively stick with (unsigned) int/long/long long, possibly wrapped in a typedef. I don't see what's the problem here. Plenty of options, pick your portability / explicitness tradeoff.
> You can easily find C code in the wild written in two (or more ) ways. Search almost any project for #if and #ifdef.
Sure, but not for this regular kind of bit-shoveling code. Mostly for platform integration. And yes, a little bit of setup code to support different compilers.