1.6　它很棒，但它符合标准吗

不要添乱——立即解散ISO工作小组。

——匿名人士

ANSI C标准可以说是非常独特的，我们可以从好几个有趣的方面来说明这一点。它定义了下面一些术语，用于描述某种编译器的特点。如果你对这些术语有一个比较好的了解，就能理解什么东西能被语言接受，什么东西不能被语言接受。前两个术语涉及不可移植的代码（unportable code），接下来的两个术语跟坏代码（bad code）有关，而最后两个术语则跟可移植的代码（portable code）有关。

不可移植的代码

由编译器定义的（implementation-defined）：由编译器设计者决定采取何种行动（就是说，在不同的编译器中所采取的行为可能并不相同，但它们都是正确的），并做好文档记录。

例如，当整型数向右移位时，要不要扩展符号位。

未确定的（unspecified）：在某些正确情况下的做法，标准并未明确规定应该怎样做。

例如，参数求值的顺序。

坏代码

未定义的（undefined）：在某些不正确情况下的做法，但标准并未规定应该怎样做。你既可以采取任何行动，也可以什么也不做，还可以发出一条警告信息，或者可以终止程序以及让CPU陷入瘫痪，甚至可以发射核导弹（只要你安装了能发射核弹的硬件系统）。

例如，当一个有符号整数溢出时该采取什么行动。

约束条件（a constraint）：这是一个必须遵守的限制或要求。如果不遵守，那么你的程序的行为就会变成上面所说的属于“未定义的”。这就出现了一种很有意思的情况：分辨某种东西是否是一个约束条件是很容易的，因为标准的每个主题都附有一个“约束”（constraint）小节，列出了所有的约束条件。现在又出现了一个更为有趣的情况：标准规定^[3]编译器只有在违反语法规则和约束条件的情况下才能产生错误信息！这意味着所有不属于约束条件的语义规则都可以不遵循，而且由于这种行为属于未定义行为，编译器可以采取任何行动，甚至不必通知你！

例如，%操作符的操作数必须属于整型。所以，在非整数数据上使用%操作符肯定会引发一条错误信息。

不属于约束条件规则的例子：所有在C语言标准头文件中声明的标识符均保留，所以不能声明一个名为malloc()的函数，因为在标准头文件里已经有一个函数以此为名。但这个规定不是约束条件，因此可以违反它，而且编译器甚至可以不警告你！关于“interpositioning”这一小节的更多内容，参见第5章。

---

　

　软件信条

未定义的行为在IBM PC中引起CPU瘫痪！

未定义的软件行为引起CPU瘫痪的说法并不像它乍听上去那样牵强。

IBM PC的显示器以显示控制芯片所提供的水平扫描速率进行工作。回扫变压器（flyback transformer，一种产生高电压的装置，用于加速电子以点亮显示器上的荧光物质）需要保持一个合理的频率。

然而在软件中，程序员有可能把视频芯片的扫描速率设置成零，这样就会产生一个恒定的电压输出到回归变压器的输入端。这就使它起了电阻器的作用，只是把电能转换成热能，而不是传送到屏幕。这会在数秒之内就把显示器烧毁，这就是未定义的软件行为会导致系统瘫痪的理由。

---

　

可移植的代码

严格遵循标准的（strictly-conforming）：一个严格遵循标准的程序应该具有如下特点。

• 只使用已确定的特性。
• 不突破任何由编译器实现的限制。
• 不产生任何依赖由编译器定义的或未确定的或未定义的特性的输出。

这样规定的主要目的就是最大限度地保证可移植性。这样，不论在什么平台上运行严格遵循标准的程序，都会产生相同的输出。事实上，在所有遵循标准的程序中，属于这一类的程序并不多。例如，下面这个程序就不是严格遵循标准的：

#include <limits.h>
#include <stdio.h>
int main() { (void)printf("biggest int is %d", INT_MAX); return 0;}

/*并不严格遵循标准，其输出结果是由编译器定义的*/

在本书的剩余部分，我们通常并不强求例子程序严格遵循标准。因为如果这样做会使文本看上去比较乱，而且不利于理解所讨论的要点。程序的可移植性是非常重要的，所以在现实编码中，应该始终保证加上必要的类型转换、返回值等。

遵循标准的（conforming）：一个遵循标准的程序可以依赖某种编译器特有的不可移植的特性。所以，一个程序有可能在一个特定的编译器里是遵循标准的，但在另一个编译器里却是不遵循标准的。它可以进行扩展，但这些扩展不能修改严格遵循标准的程序的行为。但是，这个规则并不是一个约束条件，所以对于程序中不遵循标准的地方，你不要指望编译器会给出一条警告信息指出你违反了规定！

上面所举的几个程序实例都是遵循标准的。