标签：strict-aliasing c undefined-behavior

我的一位同事正在研究与二进制数据阵列一起使用的C代码.在某些地方,他的代码就像

char *bytes = ...
T *p = (T*) bytes;
T v = p[i]; // UB

这里,T有时可以是short或int(分别假设为16和32位).

现在,与我的同事不同,我属于“没有UB,如果可能的话”阵营,而他更像是“如果有效,那就没关系”.我正在努力试图说服他.

鉴于：

>字节真的来自这个编译单元之外的某个地方,从一些二进制文件中读取.
>可以安全地假设数组实际上包含本机字节序中的整数.

在实践中,鉴于MSVC 2017和gcc 4.8以及Intel x64硬件这样的主流C编译器,这样的事情真的很安全吗？我知道如果T是浮动(过去曾被它咬过),那就不行了.

解决方法:

char *可以在不破坏严格别名规则的情况下对其他实体进行别名.

只有当最初的p i不是T时,你的代码才是UB.

char* byte = (char*) floats;
int *p = (int*) bytes;
int v = p[i]; // UB

但

char* byte = (char*) floats;
float *p = (float*) bytes;
float v = p[i]; // OK

如果byte的起源是“未知”,则编译器不能从UB中获益以进行优化,并且应该假设我们处于有效的情况并根据生成代码.
但你如何保证它是未知的？即使在TU之外,像Link-Time Optimization这样的东西也许可以提供隐藏的信息.

标签：strict-aliasing,c,undefined-behavior
来源： https://codeday.me/bug/20190910/1800376.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。