作为一名程序员，如果说沉迷一门编程语言算作一种乐趣的话，那么与此同时反过来去黑一门编程语言就是这种乐趣的升华。今天我们就来黑一把C语言，好好展示一下这门经典语言令人抓狂的一面。
对于计算机来说，它可能是具有地址的一块内存(memory)。
从空间分配上看，定义且初始化的全局变量在编译时在数据段(.data)分配空间，定义但未初始化的全局变量**暂存(tentative definition)**在.bss段，编译时自动清零，而仅仅是声明的全局变量只能算个符号，寄存在编译器的符号表内，不会分配空间，直到链接或者运行时再重定向到相应的地址上。
/* t.h */
#ifndef _H_
#define _H_
int a;
#endif
/* foo.c */
#include
#include "t.h"
struct {
char a;
int b;
} b = { 2, 4 };
int main();
void foo()
{
printf("foo:\t(&a)=0x%08x\n\t(&b)=0x%08x\n
\tsizeof(b)=%d\n\tb.a=%d\n\tb.b=%d\n\tmain:0x%08x\n",
&a, &b, sizeof b, b.a, b.b, main);
}
/* main.c */
#include
#include "t.h"
int b;
int c;
int main()
{
foo();
printf("main:\t(&a)=0x%08x\n\t(&b)=0x%08x\n
\t(&c)=0x%08x\n\tsize(b)=%d\n\tb=%d\n\tc=%d\n",
&a, &b, &c, sizeof b, b, c);
return 0;
}Makefile 如下：
test: main.o foo.o
gcc -o test main.o foo.o
main.o: main.c
foo.o: foo.c
clean:
rm *.o test运行情况：
foo: (&a)=0x0804a024
(&b)=0x0804a014
sizeof(b)=8
b.a=2
b.b=4
main:0x080483e4
main: (&a)=0x0804a024
(&b)=0x0804a014
(&c)=0x0804a028
size(b)=4
b=2
c=0这个项目里我们定义了四个全局变量，t.h头文件定义了一个整型a，main.c里定义了两个整型b和c并且未初始化，foo.c里定义了一个初始化了的结构体，还定义了一个main的函数指针变量。
由于C语言每个源文件单独编译，所以t.h分别包含了两次，所以int a就被定义了两次。两个源文件里变量b和函数指针变量main被重复定义了，实际上可以看做代码段的地址。但编译器并未报错，只给出一条警告：
/usr/bin/ld: Warning: size of symbol 'b' changed from 4 in main.o to 8 in foo.o运行程序发现，main.c打印中b大小是4个字节，而foo.c是8个字节，因为sizeof关键字是编译时决议，而源文件中对b类型定义不一样。
但令人惊奇的是无论是在main.c还是foo.c中，a和b都是相同的地址，也就是说，a和b被定义了两次，b还是不同类型，但内存映像中只有一份拷贝。
我们还看到，main.c中b的值居然就是foo.c中结构体第一个成员变量b.a的值，这证实了前面的推断——**即便存在多次定义，内存中只有一份初始化的拷贝。**另外在这里c是置身事外的一个独立变量。
为何会这样呢？这涉及到C编译器对多重定义的全局符号的解析和链接。
如果有多个弱符号，那么先决议到size最大的那个，如果同样大小，则按照链接顺序选择第一个。
像上面这个例子中，全局变量a和b存在重复定义。如果我们将main.c中的b初始化赋值，那么就存在两个强符号而违反了规则一，编译器报错。
如果满足规则二，则仅仅提出警告，实际运行时决议的是foo.c中的强符号。而变量a都是弱符号，所以只选择一个（按照目标文件链接时的顺序）。
/* foo.c */
#include
struct {
int a;
int b;
} b = { 2, 4 };
int main();
void foo()
{
printf("foo:\t(&b)=0x%08x\n\tsizeof(b)=%d\n
\tb.a=%d\n\tb.b=%d\n\tmain:0x%08x\n",
&b, sizeof b, b.a, b.b, main);
}
/* main.c */
#include
int b;
int c;
int main()
{
if (0 == fork()) {
sleep(1);
b = 1;
printf("child:\tsleep(1)\n\t(&b):0x%08x\n
\t(&c)=0x%08x\n\tsizeof(b)=%d\n\tset b=%d\n\tc=%d\n",
&b, &c, sizeof b, b, c);
foo();
} else {
foo();
printf("parent:\t(&b)=0x%08x\n\t(&c)=0x%08x\n
\tsizeof(b)=%d\n\tb=%d\n\tc=%d\n\twait child...\n",
&b, &c, sizeof b, b, c);
wait(-1);
printf("parent:\tchild over\n\t(&b)=0x%08x\n
\t(&c)=0x%08x\n\tsizeof(b)=%d\n\tb=%d\n\tc=%d\n",
&b, &c, sizeof b, b, c);
}
return 0;
}运行情况如下：
foo: (&b)=0x0804a020
sizeof(b)=8
b.a=2
b.b=4
main:0x080484c8
parent: (&b)=0x0804a020
(&c)=0x0804a034
sizeof(b)=4
b=2
c=0
wait child...
child: sleep(1)
(&b):0x0804a020
(&c)=0x0804a034
sizeof(b)=4
set b=1
c=0
foo: (&b)=0x0804a020
sizeof(b)=8
b.a=1
b.b=4
main:0x080484c8
parent: child over
(&b)=0x0804a020
(&c)=0x0804a034
sizeof(b)=4
b=2
c=0（说明一点，运行情况是直接输出到stdout的打印，笔者曾经将./test输出重定向到log中，结果发现打印的执行序列不一致，所以采用默认输出。）
这是一个多进程环境，首先我们看到无论父进程还是子进程，main.c还是foo.c，全局变量b和c的地址仍然是一致的（当然只是个逻辑地址），而且对b的大小不同模块仍然有不同的决议。
这里值得注意的是，我们在子进程中对变量b进行赋值动作，从此子进程本身包括foo()调用中，整型b以及结构体成员b.a的值都是1，而父进程中整型b和结构体成员b.a的值仍是2，但它们显示的逻辑地址仍是一致的。
个人认为可以这样解释，fork创建新进程时，子进程获得了父进程上下文“镜像”（自然包括全局变量），虚拟地址相同但属于不同的进程空间，而且此时真正映射的物理地址中只有一份拷贝，所以b的值是相同的（都是2）。
随后子进程对b改写，触发了操作系统的**写时拷贝(copy on write)**机制，这时物理内存中才产生真正的两份拷贝，分别映射到不同进程空间的虚拟地址上，但虚拟地址的值本身仍然不变，这对于应用程序来说是透明的，具有隐瞒性。
test: main.o foo.o
ar rcs libfoo.a foo.o
gcc -static -o test main.o libfoo.a
main.o: main.c
foo.o: foo.c
clean:
rm -f *.o test运行情况如下：
foo: (&b)=0x080ca008
sizeof(b)=8
b.a=2
b.b=4
main:0x08048250
parent: (&b)=0x080ca008
(&c)=0x080cc084
sizeof(b)=4
b=2
c=0
wait child...
child: sleep(1)
(&b):0x080ca008
(&c)=0x080cc084
sizeof(b)=4
set b=1
c=0
foo: (&b)=0x080ca008
sizeof(b)=8
b.a=1
b.b=4
main:0x08048250
parent: child over
(&b)=0x080ca008
(&c)=0x080cc084
sizeof(b)=4
b=2
c=0从这个例子看不出有啥差别，只不过使用静态链接后，全局变量加载的地址有所改变，b和c的地址之间似乎相隔更远了些。不过这次编译器倒是给出了变量b的sizeof决议警告。
到此为止，有些人可能会对上面的例子嗤之以鼻，觉得这不过是列举了C语言的某些特性而已，算不上黑。
有些人认为既然如此，对于一切全局变量要么用static限死，要么定义同时初始化，杜绝弱符号，以便在编译时报错检测出来。只要小心地使用，C语言还是很完美的嘛~
/* foo.c */
#include
const struct {
int a;
int b;
} b = { 3, 3 };
int main();
void foo()
{
b.a = 4;
b.b = 4;
printf("foo:\t(&b)=0x%08x\n\tsizeof(b)=%d\n
\tb.a=%d\n\tb.b=%d\n\tmain:0x%08x\n",
&b, sizeof b, b.a, b.b, main);
}
/* t1.c */
#include
int b = 1;
int c = 1;
int main()
{
int count = 5;
while (count-- > 0) {
t2();
foo();
printf("t1:\t(&b)=0x%08x\n\t(&c)=0x%08x\n
\tsizeof(b)=%d\n\tb=%d\n\tc=%d\n",
&b, &c, sizeof b, b, c);
sleep(1);
}
return 0;
}
/* t2.c */
#include
int b;
int c;
int t2()
{
printf("t2:\t(&b)=0x%08x\n\t(&c)=0x%08x\n
\tsizeof(b)=%d\n\tb=%d\n\tc=%d\n",
&b, &c, sizeof b, b, c);
return 0;
}Makefile脚本：
export LD_LIBRARY_PATH:=.
all: test
./test
test: t1.o t2.o
gcc -shared -fPIC -o libfoo.so foo.c
gcc -o test t1.o t2.o -L. -lfoo
t1.o: t1.c
t2.o: t2.c
.PHONY:clean
clean:
rm -f *.o *.so test*执行结果：
./test
t2: (&b)=0x0804a01c
(&c)=0x0804a020
sizeof(b)=4
b=1
c=1
foo: (&b)=0x0804a01c
sizeof(b)=8
b.a=4
b.b=4
main:0x08048564
t1: (&b)=0x0804a01c
(&c)=0x0804a020
sizeof(b)=4
b=4
c=4
t2: (&b)=0x0804a01c
(&c)=0x0804a020
sizeof(b)=4
b=4
c=4
foo: (&b)=0x0804a01c
sizeof(b)=8
b.a=4
b.b=4
main:0x08048564
t1: (&b)=0x0804a01c
(&c)=0x0804a020
sizeof(b)=4
b=4
c=4
...其实前面几个例子只是开胃小菜而已，真正的大坑终于出现了！而且这次编译器既没报错也没警告，但我们确实眼睁睁地看到作为main()中强符号的b被改写了，而且一旁的c也“躺枪”了。
眼尖的读者发现，这次foo.c是作为动态链接库运行时加载的，当t1第一次调用t2时，libfoo.so还未加载，一旦调用了foo函数，b立马中弹，而且c的地址居然还相邻着b，这使得c一同中弹了。
不过笔者有些无法解释这种行为的原因，有种说法是强符号的全局变量在数据段中是连续分布的（相应的弱符号暂存在.bss段或者符号表里），或许可以上报GNU的编译器开发小组。
另外笔者尝试过将t1.c中的b和c定义前面加上const限定词，编译器仍然默认通过，但程序在main()中第一次调用foo()时触发了Segment fault异常导致崩溃，在foo.c里使用指针改写它也一样。
推断这是GCC对const常量所在地址启用了类似操作系统写保护机制，但我无法确定早期版本的GCC是否会让这个const常量被改写而程序不会崩溃。
至于volatile关键词之于全局变量，自测似乎没有影响。
怎么样？看了最后一个例子是否有点“不明觉厉”呢？
C语言在你心目中是否还是当初那个“纯洁”、“干净”、“行为一致”的姑娘呢？也许趁着你不注意的时候她会偷偷给你戴顶绿帽，这一切都是通过全局变量，特别在动态链接的环境下，就算全部定义成强符号仍然无法为编译器所察觉。
而一些IT界“恐怖分子”也经常**将恶意代码包装成全局变量注入到root权限下存在漏洞的操作序列中，**就像著名的栈溢出攻击那样。某一天当你傻傻地看着一个程序出现未定义的行为却无法定位原因的时候，请不要忘记Richie大爷那来自九泉之下最深沉的“问候”~
或许有些人会偷换概念，把这一切归咎于编译器和链接器身上，认为这同语言无关，但我要提醒你，正是编译/链接器的行为支撑了整个语言的语法和语义。
你可以反过来思考一下为何C的胞弟C++推出**“命名空间(namespace)”**的概念，或者你可以使用其它高级语言，对于重定义的全局变量是否能通过编译这一关。
所以请时刻谨记，C是一门很恐怖的语言！
本文整理自网络，版权归原作者所有，如有侵权，请联系删除。
往期推荐
来都来了，点个 在看 再走吧~~~
