C语言陷阱

qc1iu published this page · Last modified:
最近一直做C编译器相关的开发,感觉该总结一下。以前一直以为对C已经足够熟悉了,结果被它奇葩的语法树震惊了。碰巧最近心血来潮,想把一个GNU的僵尸项目jamvm救活改造一下,又发现了GCC的一些奇葩C语言扩展。

声明

C语言的声明足够奇怪,以至于丑鱼书用了一章来解释这个问题。对于一般的变量声明,C语言采用的语法一般是T var的形式,T表示变量的类型,var表示变量的名字。但对于数组的声明,如果要声明一个大小为10的int数组a,C语言需要

int a[10]

而不是

int[10] a

而许多其他的语言采用的往往是类似后者的方式,比如Java,C#,Go等等。

函数的声明同样的问题。比如这样的一个函数

int foo(int a, int b)
{
    return a + b;
}

它的类型可以表示为int ()(int, int), 其实一定有人发现了,如果对foo函数做前向引用的声明,我们会这么写:

int foo(int, int);

而不是

int ()(int, int) foo;

函数指针也是同样的问题,对于foo函数的指针,类型可以表示为int (*)(int, int),但声明函数指针时,我们只能

int (*f)(int, int)

即声明了一个变量f,类型为指针类型,指向目标的类型为int ()(int, int)。如果想用T var的形式声明函数指针,只能曲线救国,利用typedef。

C语言之所以把声明形式搞得这么复杂,原因或许是为了追求变量的定义和使用尽量写法上保持一致。怎么样,是不是很奇怪?除了引入复杂性,本身完全不一样的两个概念非要写的一样有何用?比如这个声明是啥意思?

char* const *(*next)()

左值

先说结论。C99标准明确说明了Cast不能作为左值,所以现在的编译器(gcc4.x或者clang3.x)遇到这种情况都会complain。但是老版本gcc居然有一个扩展,名曰casts-as-lvalue。

左值可以简单理解为允许被赋值的值,可以被放在赋值号(=)左边的值。那什么样的值可以放在赋值号左边?权威的解答需要参考ISO/IEC 9899:1999。为了方便我用CIL对左值的定义举例

lval =
     | Mem of exp
     | Var of varinfo

可以看到左值如果是一个表达式,那么一定只一个访存操作。比如*(ptr+1) = 1,显然这里的ptr是一个指针类型。在编译jamvm1.0版本源码的时候,出现了大量的lvalue required as left operand of assignment错误。这里错误大部分都长的这个样*((long long*)ptr)++ = 1。我根据代码上下文理解,它是想根据强制类型转换后的类型进行指针自增操作。不过经过我调研,发现现在的编译器已经不支持一行代码实现类似这样语义的操作了。如果想要编译含有这样语句的C代码,可以尝试使用gcc3.3.6。gcc3.3.6支持cast-as-lvalue扩展,但是本身并不含有cast-as-lvalue的代码。

undefined behaviour

只举个例子。比如*p++ = p[-1],赋值号两边的计算顺序不同编译器是不同的,C标准对它没有做严格的要求。所以这种写法在开发中一定要避免,clang默认会抛一个warning,gcc不加-Wall参数不会有任何提示。

总结

  1. 不要为了少写一两行代码而是用一些非标准的extenstion或者trick,得不偿失。
  2. Treat all warning as error !

对JVM感兴趣的话,jamvm1.0的确是个不错的起点,不到7000行的C,实现了一个java虚拟机该有的几乎所有功能。问题是现在的主流编译器都无法编译它了。neojam是对jamvm1.0代码修改后可以用gcc4.x编译的版本,链接先放在这,相关文档补全后会public。