C语言语法简单，但内涵却博大精深；如果在学习时只是止步于表面，那么往往后期会遇到很多困难。typedef是C语言中一个很好用的工具，大量存在于已有代码中，特别值得一提的是：C++标准库实现中更是对typedef有着大量的使用。但很多初学者对其的理解仅局限于：typedef用来定义一个已有类型的”别名(alias)”。正是因为有了这样的理解，才有了后来初学者在typedef int myint和typedef myint int之间的犹豫不决。很多国内大学的C语言课之授课老师也都是如是说的，或者老师讲的不够透彻，导致学生们都是如是理解的。我这里想结合C语言标准文档以及一些代码实例，也说说typedef。

int    *p;
这样的代码是C语言中最最基础的一个语句了，大家都知道这个语句声明了一个变量p，其类型是指向整型的指针(pointer to int)；如果在这个声明的前面加上一个typedef后，整个语义(semantics)又会是如何改变的呢？
typedef  int    *p;

我们先来看看C99标准中关于typedef是如何诠释的？C99标准中这样一小段精辟的描述：”In a declaration whose storage-class specifier is typedef, each declarator defines an identifier to be a typedef name that denotes the type specified for the identifier in the way described in xx”。

参照这段描述，并拿typedef  int    *p作为例子来理解：在一个声明中，如果有存储类说明符typedef的修饰，标识符p将被定义为了一个typedef name，这个typedef name表示(denotes)一个类型，什么类型呢？就是int *p这个声明(declarator)中标识符(indentifier)p的类型(int*)。

再比对一下两个声明：
int    *p;
typedef  int    *p;
是不是有点”茅舍顿开”的感觉，int *p中, p是一个变量，其类型为pointer to int；在int *p前面增加一个typedef后，p变为一个typedef-name，这个typedef-name所表示的类型就是int *p声明式中p的类型(int*)。说句白话，typedef让p去除了普通变量的身份，摇身一变，变成了p的类型的一个typedef-name了。

为了巩固上面的理解，我们再来看看”C语言参考手册(C: A Reference Manual)”中的说法：任何declarator(如typedef int   *p)中的indentifier(如p)定义为typedef-name， 其(指代p)表示的类型是declarator为正常变量声明(指代int  *p)的那个标识符(指代p)的类型(int*)。有些绕嘴，不过有例子支撑：

[例1]
typedef double MYDOUBLE;  

分析:
去掉typedef ，得到正常变量声明=> double MYDOUBLE;
变量MYDOUBLE的类型为double;
=> “typedef double MYDOUBLE”中MYDOUBLE是类型double的一个typedef-name。

MYDOUBLE    d; <=> d是一个double类型的变量

[例2]
typedef double *Dp;  

分析:
去掉typedef  ，得到正常变量声明=> double *Dp;
变量Dp的类型为double*，即pointer to double;
=> “typedef double *Dp”中Dp是类型double*的一个typedef-name。

Dp    dptr; <=> dptr是一个pointer to double的变量

[例3]
typedef int* Func(int);

分析:
去掉typedef  ，得到正常变量声明=> int* Func(int);
变量Func的类型为一个函数标识符，该函数返回值类型为int*，参数类型为int;
=> “typedef int* Func(int)”中Func是函数类型(函数返回值类型为int*，参数类型为int)的一个typedef-name。

Func    *fptr; <=> fptr是一个pointer to function with one int parameter, returning a pointer to int
Func     f;   这样的声明意义就不大了。

[例4]
typedef int (*PFunc)(int);

分析:
去掉typedef  ，得到正常变量声明=> int (*PFunc)(int);
变量PFunc的类型为一个函数指针，指向的返回值类型为int，参数类型为int的函数原型;
=> “typedef int (*PFunc)(int)”中PFunc是函数指针类型(该指针类型指向返回值类型为int，参数类型为int的函数)的一个typedef-name。

PFunc     fptr; <=> fptr是一个pointer to function with one int parameter, returning int

[例5]
typedef    int   A[5];

分析:
去掉typedef ，得到正常变量声明 => int   A[5];
变量A的类型为一个含有5个元素的整型数组；
=> “typedef    int   A[5]“中A是含有5个元素的数组类型的一个typedef-name。

A   a = {3, 4, 5, 7, 8};
A   b = { 3, 4, 5, 7, 8, 9}; /* 会给出Warning: excess elements in array initializer */

[例6]
typedef    int   (*A)[5]; (注意与typedef    int*    A[5]; 区分)

分析:
去掉typedef ，得到正常变量声明 => int   (*A)[5];
变量A的类型为pointer to an array with 5 int elements；
=> “typedef    int   (*A)[5]“中A是”pointer to an array with 5 int elements”的一个typedef-name。

int   c[5] = {3, 4, 5, 7, 8};  
A    a = &c;
printf(“%d\n”, (*a)[0]); /* output: 3 */

如果这样赋值：
int   c[6] = {3, 4, 5, 7, 8, 9};  
A    a = &c; /* 会有Warning: initialization from incompatible pointer type */

[例7]
typedef struct _Foo_t Foo_t;

分析:
去掉typedef ，得到正常变量声明 => struct _Foo_t Foo_t;
变量Foo_t的类型为struct _Foo_t;
=> “typedef struct _Foo_t Foo_t”中Foo_t是”struct _Foo_t”的一个typedef-name。

[例8]
typedef   struct { … // }   Foo_t;

分析:
去掉typedef ，得到正常变量声明 => struct { … // }   Foo_t;
变量Foo_t的类型为struct { … // } ;
=> “typedef   struct { … // }   Foo_t “中Foo_t是”struct { … // }”的一个typedef-name。这里struct {…//}是一个无”标志名称(tag name)”的结构体声明。

[例9]
typedef      struct { … // }   Foo_t[1];

分析：
去掉typedef ，得到正常变量声明 => struct { … // }   Foo_t[1];
变量Foo_t的类型为包含一个元素的struct { … // }类别的数组类型;
=> 这样一来，Foo_t在typedef定义后实际上就变成了一个struct { … // }数组类型。要问实际编程中会这么用typedef吗？你还别说，这还是C语言常用的一个小技巧，如果你有机会看到jmp_buf的类型定义，你就会发现jmp_buf在很多系统实现中也是如此定义的，大约类似：typedef struct XX {…} jmp_buf[1]; 这样做的目的大致是这样的：如果你在函数里定义了一个char a[n]；那么a和&a作为参数传入某个函数时是等价的。看似传值，实则传址，在被调用函数中通过参数可直接修改数组a的元素的内容。另外这么做的目的是否是为了让代码更符合某些人的口味我还不得而知。

参考资料：
1、”ISOIEC-98991999(E)–Programming Languages–C”之Page 123;
2、C语言参考手册(中文版) 之 Page 119

曾经在多篇blog中报怨过：用C语言写业务逻辑实在是让人身心忐忑不安，再加之C语言自有的"特点"，让其与"单元测试"始终若即若离，曾经尝试过写了一个轻量级C Unit Testing lib，至少目前我依旧在用，但多用在编写独立算法以及底层库的场合。业务层少有使用。业务层多是遗留系统，当初前辈们设计时对可测性考虑不够周全，导致现在无法很好的将各个部分独立抽出进行测试，虽然我们也在做着类似"重构"的工作，但鉴于规模较大，不能一蹴而就，我们需要一步一步找出使用C应对各种单元测试情况的方法。这里说说Mock Test。

在系统中，我们不可避免的要调用一些外部或者系统级别的接口，而我们在测试时这些接口的环境也许并不存在，但是我们测试业务流程时还是要覆盖到所有的，业界就提出了Mock这个概念，最开始在Java开发领域，后来在其他语言中都有引入。Mock是一种什么东西？其实感觉就是给你一个机会，一种模拟和控制外部/系统级别对象或者接口的方法，这样你大可在不必与真实环境交互的前提下就完成所有依赖外部环境的业务流程的覆盖测试。Mock Test在许多语言中都有支持，但是在C语言中，Mock的支持似乎少之又少，在Cgreen这个C Unit test framework中虽然支持Mock，但是其要求你的待测试的业务接口必须附加一个stub参数，这样具有"侵入性"的设计让我感觉很是别扭，而且对于外部接口，你更是无法改变其接口原型，那么能否有其他的方法呢？这里放出一种我的方案，也不甚完美。

C语言有其自身的特色，我这里利用的就是其在编译时的一些特色：先进行预编译，再进行编译和链接。我试着在两个阶段之间做一个trick，以达到我的目的-Mock。

一般我们这样编写一个业务模块：
/* biz.h */
#ifndef BIZ_H
#define BIZ_H

#include

int biz_operation(char *fname);
#endif

/* biz.c */
#include "biz.h"

int biz_operation(char *fname) {
        FILE *fp = NULL;

        fp = fopen(fname, "r");
        if (fp == NULL) {
                printf("fail to open fle!\n");
                return 1;
        } else {
                printf("succeed to open file!\n");
                return 0;
        }
}
这个业务模块有一个业务操作流程，试图只读方式打开一个文件。如果没有mock辅助，我们在测试时需要在环境下手工创建一个文件，这样才能返回"成功"，否则一直就是"失败"，"成功"分支也就无法测试得到。

我们先建立我们的单元测试代码文件：
/* test.c */
#include "biz.h"

void test_biz_operation_return_succ() {
        int rv;
        rv = biz_operation("test-c-mock.txt");
        xx_assert(rv == 0);
}

int main() {
        … …
        /* 无论采用什么单元测试框架，都会有直接或者间接的类似如下调用：*/
        test_biz_operation_return_succ();
        … …
}
biz_operation依赖一个fopen的C标准库调用，我们如何去做一个fopen的mock接口呢？前面说过，我们要利用C的两阶段编译的特色来完成这个mock。我们增加一个mock.h和一个对应的mock.c，我们在这对文件中实现我们自己对fopen的控制。
/* mock.h */
#ifndef MOCK_H
#define MOCK_H

#include

FILE* mock_fopen(char *fname, char *option);
#endif

/* mock.c */
#include "mock.h"

FILE* mock_fopen(char *fname,  char *option) {
        return (FILE*)0×12345678; //在这里，你可以自由控制返回结果
}

如何将mock_fopen与fopen联系在一起呢？我们通过gcc提供的-D选项来做。我们形象化的说一下：
上述源文件的目录结构如下：
/export/home/mock_test
  - biz/
  - test/
我们在test目录下新建一个Makefile文件，用来自动完成test的编译。
## Makefile ##
BIZOBJDIR = /export/home/mock_test/biz
BIZOBJ = $(BIZOBJDIR)/mock_biz.o
BIZSRC = $(BIZOBJDIR)/biz.c

TESTSRC = test.c mock.c
TESTOBJ = test.o mock.o

MOCK_FLAG = -Dfopen=mock_fopen # 关键之处

all:
        gcc $(MOCK_FLAG) -c -o $(BIZOBJ) $(BIZSRC)
        gcc -c $(TESTSRC) -I$(BIZOBJDIR)
        gcc -o test $(TESTOBJ) $(BIZOBJ)

我们从理论上分析一下这种方法的可行性：我们先将biz.c编译成.o文件，MOCK_FLAG将biz.c中的fopen替换成了mock_fopen，这些都是预编译器的功劳；然后我们在test目录下，将test.c 和mock.c编译为对应的.o文件，这里无需使用MOCK_FLAG，否则会有compile error发生；最后一步进行链接：test.o中的biz_operation符号在mock_biz.o中被resolved，而mock_biz.o中的biz_operation在mock.o中被resolved。这样链接后，

fopen处实际上调用的是mock_fopen，也就是那个你可以自由控制的接口。如果在biz.c中还有其他系统调用，比如write, read等，我们都可以

将其mock加到mock.c中，比如称为mock_write和mock_read，然后更新MOCK_FLAG = -Dfopen=mock_fopen -Dwrite=mock_write -Dread=mock_read等。

以上结果已经在Solaris上GCC下测试通过了，目前这种想法还不成够熟，也只是在单个业务模块下做了些测试，下一步如果能做到整个工程的单元测试那就更好了。鉴于上面的情况，如果mock过多，对Makefile的维护任务将有很大加重，实现全工程的单元测试集中还需时日。