Comment by matvore

4 hours ago

You would still want a native 16 bit type in order to have a pointer to a 16-bit memory location, including an array of 16-bit values.

4 comments

matvore

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

  • matvore  3 hours ago

    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.

    • sparkie  3 hours ago

      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.