3 ms·
I'd argue it's more like only 40% of the way to a proper ABI; sizeof(long) varying on the same CPU architecture is just horrible. Sure, it wasn't meant to be an
by dzaima 5y ago
I'd argue it's more like only 40% of the way to a proper ABI; sizeof(long) varying on the same CPU architecture is just horrible. Sure, it wasn't meant to be an ABI, but, well, it is. And we're stuck with it. And oh how nice would it be if we weren't.
- lelanthran 5y ago> sizeof(long) varying on the same CPU architecture is just horrible. On the other hand, `sizeof (int8_t)` is the same size no matter which architecture you are running on. If you, as the programmer, are depending on the bit-width of an integer type, C has got you covered mostly.
- dzaima 5y agoi mean, if sizeof(int8_t) varied, noone would even try to use C as a lingua franca. I, as the programmer, would never expose unknown width integer types, but other things still will, and I'll be forced to interact with them. Allowing such things to even be present in an ABI is just horrible.
- acuozzo 5y ago> On the other hand, `sizeof (int8_t)` is the same size no matter which architecture you are running on. EDIT: See account42's reply below. ORIGINAL COMMENT: No, it's not. CHAR_BIT is not required to be 8 and sizeof (int8_t) is not required to be 1. Hell, int8_t is not even required to be present in <stdint.h>, but int_least8_t is.
- dzaima 5y agohuh, I guess that's still not hard-coded. But a non-8-bit-byte system probably runs near nothing to interface with anyway, and would definitely need a completely separate ABI in any scenario.
- account42 5y agoCHAR_BIT is required to be at least 8, int8_t is required to be exactly 8 bits if present, sizeof(int8_t) is required to return an integer size where sizeof(char) is 1. Hence, if int8_t is present then CHAR_BIT must be 8 and sizeof(int8_t) == 1.
- steveklabnik 5y agoTo add a teeny bit to this, POSIX specifies CHAR_BIT must be 8, but C defines it as >= 8.