← Back to context

Comment by debugnik

4 hours ago

I don't think of the stdint types as being less native than the keyword integer types. C# for example makes keyword types aliases to System.* types, not the other way around.

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.

  • 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.