1993年SUN erf函数中指针算术转换代码的作用问询

我在查看一段1993年SUN版权的erf函数代码时，对其中的((*(int*)&one)>>29)^1表达式感到困惑，调试时该结果始终为1，想知道这是不是当时的旧编译器技巧。相关代码片段如下：

static const double one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
int n0,hx,ix,i;
double R,S,P,Q,s,y,z,r;
n0 = ((*(int*)&one)>>29)^1;
hx = *(n0+(int*)&x);

完整函数片段：

double erf(double x)
{
  int n0,hx,ix,i;
  double R,S,P,Q,s,y,z,r;
  n0 = ((*(int*)&one)>>29)^1;
  hx = *(n0+(int*)&x);
  ix = hx&0x7fffffff;
  if(ix>=0x7ff00000) { /* erf(nan)=nan */
    i = ((unsigned)hx>>31)<<1;
    return (double)(1-i)+one/x; /* erf(+-inf)=+-1 */
  }

  if(ix < 0x3feb0000) { /* |x|<0.84375 */
  // ... 省略后续代码
}

表达式的核心作用：跨字节序获取double的高32位 #

这段代码是针对大端/小端字节序的兼容技巧，目的是无论系统采用哪种字节序，都能正确读取double类型变量x的高32位（包含符号位和指数位，是后续判断NaN、无穷大、数值范围的关键）。

拆解表达式((*(int*)&one)>>29)^1：

• *(int*)&one：将double类型的one（值为1.0，IEEE754双精度表示为0x3FF00000 0x00000000）强制转换为int*指针后取值。大端系统中取到的是高位0x3FF00000，小端系统中取到的是低位0x00000000。
• >>29：将上述结果右移29位。大端下结果为1，小端下结果为0。
• ^1：与1做异或操作。大端下结果为0，小端下结果为1。

后续hx = *(n0+(int*)&x)：

• 大端系统中n0=0，直接取x的第一个32位（高32位）；
• 小端系统中n0=1，取x的第二个32位（高32位）。

为什么调试结果始终为1？ #

现在主流的x86/x86_64架构都是小端字节序，因此这个表达式的计算结果必然是1，属于正常现象。

这确实是旧时代的编译器技巧 #

1993年时，C标准没有提供直接访问浮点数二进制表示的标准方法，也没有统一的跨平台字节序处理方式。这段代码通过硬编码1.0的IEEE754表示，自动判断系统字节序，从而正确获取浮点数的高32位，是当时为实现跨平台兼容的底层技巧。

内容的提问来源于stack exchange，提问作者Augunrik