7.1 测试包代码中使用的习惯用法

通常，C 测试用例以-n.c结尾，并且从-1.c开始， 以便于以后增加其它具有类似名字的测试用例。 如果是测试一些明确定义的特征，则测试的名字应该指出这个特征， 例如feature-1.c。如果不是测试一个明确定义的特征， 而只是检验在编译器中存在的，并且是在GCC bug库中归档的bug， 则可以使用prbug-number-1.c这样的名字形式。 否则（对于在GCC bug库中没有归档的各种bug）， 测试用例根据它们被添加的日期来命名，这种情况在以前更加常见。 这样使人们能够一眼看出一个测试失败是由于一个新发现并且还没有被修复的bug造成的， 还是由于一个回退错误造成的，但它并没有给出关于bug的其它信息， 以及从哪里可以找到相关的讨论。一些其它语言的测试包也遵守类似的惯例。

在gcc.dg测试包中，通常需要测试一个错误确实是硬件错误， 而不只是一个警告——例如，在C标准中的violatile限定， 在有-pedantic-errors的时候必须为一个错误。为此， 可以使用下面的习惯用法，其中第一行为产生错误的文件的行line。

     /* { dg-bogus "warning" "warning in place of error" } */
     /* { dg-error "regexp" "message" { target *-*-* } line } */

可能需要检查一个表达式为整数常量表达式，并且具有一个特定的值。 要检查E具有值V，可以使用类似下面的习惯用法：

     char x[((E) == (V) ? 1 : -1)];

在gcc.dg测试中，__typeof__有时被用于表达式类型的断言。 例如，可以参见gcc.dg/c99-condexpr-1.c。 更加巧妙的用法依靠了C标准中条件表达式类型的确切规则； 例如，可以参见gcc.dg/c99-intconst-1.c。

如果能够测试优化被做的很适当会很有帮助。这并不能在所有情况下都能做到， 但对于可以使得代码被优化掉的情况 （例如，流分析或别名分析应该显示那样的代码不会被调用）， 或者函数将不被调用，因为它们已经被扩展为内建的函数时，是可以做到的。 这样的测试在gcc.c-torture/execute中。 在将要被优化掉的代码的地方，可以插入一个像link_failure () 这样的对一个不存在的函数的调用；并且还需要如下定义，

     #ifndef __OPTIMIZE__
     void
     link_failure (void)
     {
       abort ();
     }
     #endif

从而使得当测试在没有优化而运行时，连接依然成功。 当对一个内建函数的所有调用都已经被优化，并且不会剩下对函数的非内建版本的调用时， 那个函数可以定义为static，并且调用abort () （虽然将函数声明为静态的可能不会在所有的目标上工作）。

所有测试用例都必须是可移植的。 目标特定的测试用例必须具有适当的代码来避免在不支持的系统上引起失败； 不幸的是，这种机制随目录有所不同。

FIXME: 讨论一下非C的测试包。