uint8_t可以是非字符类型吗？

发布时间：2020-12-14 00:40:30 所属栏目：Windows 来源：网络整理

导读：在 this answer和附加的注释中,Pavel Minaev提出以下参数,在C中,uint8_t可以被typedef的唯一类型是char和unsigned char.我正在查看 this draft的C标准. uint8_t的存在意味着存在相应的类型int8_t(7.18.1p1). int8_t是8位宽,没有填充位(7.18.1.1p1). 相应的类

在 this answer和附加的注释中,Pavel Minaev提出以下参数,在C中,uint8_t可以被typedef的唯一类型是char和unsigned char.我正在查看 this draft的C标准.

> uint8_t的存在意味着存在相应的类型int8_t(7.18.1p1).
> int8_t是8位宽,没有填充位(7.18.1.1p1).
>相应的类型具有相同的宽度(6.2.5p6),因此uint8_t也是8位宽.
> unsigned char是CHAR_BIT位宽(5.2.4.2.1p2和6.2.6.1p3).
> CHAR_BIT至少为8(5.2.4.2.1p1).
> CHAR_BIT最多为8,因为uint8_t是unsigned char,或者是一个非无符号字符,非位域类型,其宽度是CHAR_BIT(6.2.6.1p4)的倍数.

基于这个参数,我同意,如果uint8_t存在,那么它和unsigned char都具有相同的表示：8个值位和0个填充位.这似乎并不迫使它们是同一类型(例如,6.2.5p14).

是否允许将uint8_t typedef’d扩展为无符号整数类型(6.2.5p6),具有与unsigned char相同的表示形式？当然,它必须是typedef’d(7.18.1.1p2),它不能是除unsigned char之外的任何标准无符号整数类型(或char,如果它是没有符号的).这种假设的扩展类型不会是一个字符类型(6.2.5p15),因此不符合别名访问不兼容类型(6.5p7)的对象,因为编译器作者想要这样做事情.

如果uint8_t存在,则无填充要求意味着CHAR_BIT为8.但是,没有根本原因可以找到为什么uint8_t不能用扩展整数类型定义.此外,不能保证这些陈述是一致的;例如,位可以以相反的顺序解释.

虽然这对于uint8_t来说似乎是愚蠢和无礼的,但是对于int8_t来说,这可能是很有意义的.如果机器本身使用一个补码或符号/幅度,那么signed char不适用于int8_t.但是,它可以使用扩展的带符号整数类型来模拟二进制补码来提供int8_t.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!