C's Flexible Integer Sizes Were Not a Design Mistake

Re:C's Flexible Integer Sizes Were Not a Design Mistake by matvore on Sunday September 27, 2026 @04:32PM (#49870525)

I think you would need to have a compiler intrinsic type which is 16 bits. That is what the stdint.h file would define (u)int_16 to.

It would be odd for there to be a compiler intrinsic type to be unavailable until a header was included.

The compiler intrinsic type could be a mess like __int16_exactly_t but without it stdint.h would have some magic line which makes a compiler intrinsic available which wasn't before, or generates a new 16-bit type ex nihilo.

So you could have a "#pragma expose_extra_types" in stdint.h but that would not be the conventional approach.

I mostly wanted to make the point that a mere "at least 16 bits" type is not sufficient for some use cases, which is not in response to you but the comment you responded to.

[ Parent | on HN ]

Re:C's Flexible Integer Sizes Were Not a Design Mistake by sparkie on Sunday September 27, 2026 @04:58PM (#49870758)

Yeah, in GCC for example, we can define exact width types without including `<stdint.h>`.

    typedef unsigned __attribute__((mode(HI))) uint16_t;
    typedef signed __attribute__((mode(SI))) int32_t;

Of course, the mode needs to be supported by the compiler for the target arch, but we don't need to include anything.

[ Parent | on HN ]