c语言return陷阱小结,C语言陷阱

最近一直做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参数不会有任何提示。

总结

不要为了少写一两行代码而是用一些非标准的extenstion或者trick，得不偿失。

Treat all warning as error ！

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