请测试以下代码：
#include <stdio.h>
#include <stdlib.h>
main()
{
const char *yytext="0";
const float f=(float)atof(yytext);
size_t t = *((size_t*)&f);
printf("t should be 0 but is %d\n", t);
}
使用以下命令进行编译：
gcc -O3 test.c
良好的输出应该是：
"t should be 0 but is 0"
然而，我的gcc 4.1.3版本却出现了以下问题：
"t should be 0 but is -1209357172"
请使用编译器标志-fno-strict-aliasing。
启用严格别名检查时，至少在-O3默认情况下，在以下行中：
size_t t = *((size_t*)&f);
size_t t = *((size_t*)(char*)&f);
这是一段糟糕的 C 代码 :-)
问题在于你把一个 float 类型的对象强制转换成整数指针，并对其进行了解引用操作。
这违反了别名规则，编译器不能假设不同类型的指针（例如 float 或 int）在内存中不重叠。然而你却做到了。
编译器看到的是你计算了某个值，将其存储在 float 变量 f 中，但从未再次访问它。很可能编译器已经移除了部分代码，因此赋值操作从未发生过。
通过 size_t 指针进行解引用将返回堆栈中的一些未初始化垃圾数据。
你可以做两件事来解决这个问题：
使用带有 float 和 size_t 成员的 union，并通过类型转换来完成操作。虽然不太优美，但可行。
使用 memcopy 将 f 的内容复制到 size_t 中，编译器足够智能，可以检测并优化此场景。
你为什么认为 t 应该是 0 呢？
更准确地说，为什么你认为浮点数 0 的二进制表示和整数 0 的二进制表示相同呢？
这是糟糕的 C 代码。你的强制类型转换违反了 C 的别名规则，优化器可以自由地执行可能会破坏此代码的操作。你可能会发现 GCC 已经将 size_t 读取安排在浮点数写入之前（以隐藏 fp 管道延迟）。
你可以设置 -fno-strict-aliasing 开关，或使用 union 或 reinterpret_cast 以符合标准的方式重新解释值。
-O3并不被认为是“明智的选择”，-O2通常是上限，除了一些多媒体应用程序可能需要更高的优化级别。
有些应用程序甚至无法达到-O1的优化级别，如果你超过了这个级别，它们就会崩溃。
如果你使用的是足够新的GCC（我这里使用的是4.3版本），它可能支持这个命令。
gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
如果你细心一点，可能能够浏览这个列表并找到导致这个bug的独立优化。
来自man gcc：
The output is sensitive to the effects of previous command line options, so for example it is possible to find out which
optimizations are enabled at -O2 by using:
-O2 --help=optimizers
Alternatively you can discover which binary optimizations are enabled by -O3 by using:
gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
diff /tmp/O2-opts /tmp/O3-opts | grep enabled
t should be 0 but is 0
所以你的代码没有错误，并不意味着它是好的代码。 但是我会添加主函数的返回类型和在函数末尾添加"return 0;"。
％d格式说明符打印size_t表达式是UB。您需要％zu，否则需要将其转换为int。此外，size_t可能比float大（例如，在64位机器上），因此您应该使用uint32_t，它始终与IEEE 754兼容实现中的float大小相同。 - R.. GitHub STOP HELPING ICE