C语言程序员在平时工作中，到底如何获取成就感呢？我几乎可以肯定的是：找到一个隐藏已久，多年无人发现的大Bug肯定可以归属到C程序员成就感的范畴中。与操作系统斗、与编译器斗、与内存斗，其乐无穷吗^_^。

今天测试人员在进行平台迁移测试时发现一个致命的问题，导致系统不能正常工作。问题提到我这，为了不耽误测试进度，马上丢下手头的工作开始问题的查找，经过GDB多次跟踪调试，终于发现了一隐藏多年的问题，至于能否称为Bug呢，我还不敢确定，因为我尚不清楚当年的前辈们在书写这些代码时到底是如何考虑的。

前不久听说隐藏在FreeBSD系统中长达25年的一个Bug终于被Fixed了，当然今天我发现的这个问题肯定不及FreeBSD的这个Bug重要，但是对于我们的产品来说还是有很大意义的。

其实这个问题很简单，这里简单用一个例子来展示这个问题(稍后我还会用这个例子做进一步深入分析)：
/* TestFoo.c 注意该文件并不一定在所有编译器下都能顺利编译通过，警告是不可避免的了 */

typedef struct Foo {
        int     a;
        int     b;
        int     c;
} Foo;

int main() {
        Foo f;
        f.a = 17;
        f.b = 23;
        f.c = 19;

        test_foo(f);
}

void test_foo(Foo *pfoo) {
        pfoo->c = 29;
}

明眼人一眼就能看得出来，test_foo调用时，没有按照test_foo的原型传入f的地址，而是将f以值得形式传给了test_foo这个函数。就是这样的一个很低级的问题。当然了如果一个系统只有几行代码的话，这个问题可能会马上暴露出来；但是在一个拥有几十万行代码且稳定运行了若干年的系统中，没人会注意这个问题。

有人马上会提出两个疑问：
1) 为什么编译器没能给出参数类型不匹配的警告？
2) 为什么系统能在这样明显的问题下稳定运行若干年而不出错呢？

首先回答第一个问题：之所以编译器没能给出警告是因为项目遗留代码不规范的缘故，在调用test_foo这个角色函数的C文件中并没有引用test_foo原型声明所在的头文件，更不专业的是：test_foo这个函数根本没有在任何头文件中给予原型声明；这样一来，编译器在编译阶段无从知道test_foo到底是个什么样子的函数，也就无法给出正确的调用检查了。而在链接阶段根本不对参数进行有效检查，导致漏洞得以延续。

第二个问题也是今天在发现这个问题后我最最疑惑的了。按理论上分析，如果按照上述例子中代码，f以值传递方式传入test_foo，test_foo会将f的头4个字节转换成一个Foo指针类型，这样在test_foo中引用pfoo时实际上访问的地址应该是0×11(17d)，这个地址在应用程序进程地址空间属于系统地址空间，用户根本无法访问，一旦访问势必违法，如果在SUN SPARC平台上势必是要崩core的。但是实际情况是这样吗？我将上述程序放到SPARC Solaris9平台上用GCC 3.2版本编译器编译后，居然执行后一切OK。而这个源代码放到X86 Solaris 10上用GCC 3.4.6编译后(如果想编译成功，需要将test_foo的返回值改成int)运行就会出Core。初步得出结论：不同CPU体系对该种代码的处理有不同，需逐一分析。

先来看看SPARC Solaris9，用GDB跟踪程序：
Starting program: a.out

Breakpoint 1, test_foo (pfoo=0xffbff0c0) at TestFoo.c:20
20              pfoo->c = 29;
(gdb) up
#1  0x0001069c in main () at TestFoo.c:15
15              test_foo(f);
(gdb) p &f
$1 = (Foo *) 0xffbff0d0

可以看到在main中，f的地址是0xffbff0d0，而传入test_foo后，pfoo指向的地址居然是0xffbff0c0了。一个推翻前面推理的猜想：编译器在栈上复制了一份f，得到了f'，并将f'的地址传给了test_foo。但是编译器为什么要这么做呢？似乎是当编译器发现传入函数的实际参数的值类型大于形式参数类型的时候，都要这么来做，这里我也没有什么特殊的根据，只是通过实验得出这个结论。比如：

/* testvaluepass.c */
typedef struct Foo {
        int     a;
        int     b;
        int     c;
} Foo;

int main() {
        Foo     f;
        f.a     = 17;
        func(f);
}

void func(int x) {
        x = 7;
}

/* testvaluepass.s , <=gcc -S testvaluepass.c*/
main:
        !#PROLOGUE# 0
        save    %sp, -144, %sp        // 寄存器窗口切换（似乎是SPARC独有的机制），fp<- old_sp, new_sp <- old_sp – 144
        !#PROLOGUE# 1
        mov     17, %o0
        st      %o0, [%fp-32]        //%fp-32 &f.a

        ldd     [%fp-32], %o0
        std     %o0, [%fp-48]        //从%fp-48开始，复制f得到f'，先copy一个dword，再来一个word，一共12个字节
        ld      [%fp-24], %o0
        st      %o0, [%fp-40]

        add     %fp, -48, %o0        //将f'的地址存入%o0，在subroutine func中, %o0随着寄存器窗口的变动，新栈帧中%i0等于old栈帧中的%o0，也就是f'在栈上的首地址
        call    func, 0
         nop
        mov     %o0, %i0
        nop
        ret
        restore

func:
        !#PROLOGUE# 0
        save    %sp, -112, %sp
        !#PROLOGUE# 1
        st      %i0, [%fp+68]        //将f'地址写入本地变量x中
        mov     7, %i0
        st      %i0, [%fp+68]        //将7赋值给x
        nop
        ret
        restore

有了这个例子之后，我们可以分析第一个例子了，同样也是在经过汇编之后：
main:
        !#PROLOGUE# 0
        save    %sp, -144, %sp
        !#PROLOGUE# 1
        mov     17, %o0
        st      %o0, [%fp-32]
        mov     23, %o0
        st      %o0, [%fp-28]
        mov     19, %o0
        st      %o0, [%fp-24]

        ldd     [%fp-32], %o0        //这四行语句在重新复制一个f
        std     %o0, [%fp-48]
        ld      [%fp-24], %o0
        st      %o0, [%fp-40]

        add     %fp, -48, %o0         //将新f'的地址放到%o0中，而不是将[%fp-48]存入%o0，关键啊！
        call    test_foo, 0
         nop
        mov     %o0, %i0
        nop
        ret
        restore

test_foo:
        !#PROLOGUE# 0
        save    %sp, -112,         // 寄存器窗口切换，fp<- old_sp, new_sp %i0
        !#PROLOGUE# 1
        st      %i0, [%fp+68]          //%i0存储的是f’的地址，是在save时由%o0得来的，存入[%fp+68]，即形式参数变量在栈上的地址。而恰好的是这个参数还是一个Foo*类型，这也是在SPARC上没出错的原因了。
        ld      [%fp+68], %i1        //%i此时存储的是f'的地址, 这个就是gdb跟踪时的0xffbff0c0
        mov     29, %i0
        st      %i0, [%i1+8]        //将29存入f'.c里面去了
        nop
        ret
        restore

这样一来，没有出core的原因也就找到了，但是编译器为何如此做，还无法得出确切结论。

前面说过，在X86平台上，第一个例子程序是出core的，我们同样也来看看x86平台下的汇编码(与SPARC不同，esp一直在动)：
.globl main
        .type   main, @function
main:
.LFB2:
.LM1:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp        //ebp <- old sp
.LCFI1:
        subl    $24, %esp        
.LCFI2:
        andl    $-16, %esp        
        movl    $0, %eax
        addl    $15, %eax
        addl    $15, %eax
        shrl    $4, %eax
        sall    $4, %eax
        subl    %eax, %esp
.LM2:
        movl    $17, -24(%ebp)        //f.a  init %ebp-24
.LM3:
        movl    $23, -20(%ebp)        //f.b  init %ebp-20
.LM4:
        movl    $19, -16(%ebp)        //f.c  init %ebp-16
.LM5:
        subl    $4, %esp
        pushl   -16(%ebp)        //push onto stack, as first parameter
        pushl   -20(%ebp)
        pushl   -24(%ebp)       
.LCFI3:
        call    test_foo
        addl    $16, %esp
.LM6:
        leave
        ret
test_foo:
.LFB3:
.LM7:
        pushl   %ebp            //save old ebp
.LCFI4:
        movl    %esp, %ebp        //current ebp <- old esp
.LCFI5:
.LM8:
        movl    8(%ebp), %eax        //eax <- ebp + 8 ，将ebp+8那块内存的值放到%eax，而这个值恰好是0×11(17d)
        movl    $29, 8(%eax)        //访问0×11+8显然不合理，出core

看来，不同平台的编译器生成代码差异还是不小的，但是在系统里发现的这个问题到底是否定性为Bug呢?也许这样的一个问题在早期的实现者头脑里早已经是已知的了，他可能就是故意这么做的。如果真的是这样的话，那还真不能算作一个bug，而是我们水平太浅，没能意识到这点。但可以肯定的是是这样编写代码绝对是一个不好的代码风格和习惯。另外发现代码中除了这一处之外还有多处相类似的调用，多是将变量值直接付给一个地址参数了。

附:  SPARC汇编笔记

每年都有应届毕业生来到公司，每年都要对新同事进行代码方面的培训，比如编码规范就是其中之一。编码规范初听起来比较新鲜，但是培训时间长了，显然有些乏味。今年我打算改变策略，让新同事结合已有规范文档和项目代码，自己先挖掘一遍，然后大家通过坐下来讨论的互动方式来加深对规范的理解，每次讨论时间限制在1 hour以内，不给大家打瞌睡的机会^_^。

上周和新同事一起讨论表达式和语句，说到了switch和if，谈到了他们的用途和区别。大家都清楚switch语句被称为多分支语句，当代码中即将出现3个及3个以上分支时，推荐用switch，这样代码可读性好，清晰，格式工整；但是同样switch也是有局限的，就是switch(xx)中的xx必须是整型变量；如果你的条件判断是字符串比较，就无法直接使用switch了。switch的这一局限实际上是有原因的，为什么呢？在于其性能优化。那switch语句在底层到底是如何实现的呢？和if语句相比，switch除了美观之外，优势又在哪里呢？我们唯有到汇编层去看个究竟了。

我们先来看看if多分支的情况：//Windows XP + gcc v3.4.2 (mingw-special)
//testif.c
int test_if_performance(int i) {
    int rv = i;

    if (rv == 10) {
        rv += 100;
    } else if (rv == 11) {
        rv += 101;
    } else if (rv == 12) {
        rv += 102;
    } else if (rv == 13||rv == 14 || rv == 15) {
        rv += 105;
    } else {
        rv += 0;
    }
    return rv;
}

我们通过-S选项得到test_if_performance的汇编代码，我们加上了-O2的优化选项：
//gcc -S O2 testif.c
//testif.s
… …
_test_if_performance:
    pushl    %ebp
    movl    %esp, %ebp
    movl    8(%ebp), %edx
    cmpl    $10, %edx
    je    L11
    cmpl    $11, %edx
    je    L12
    cmpl    $12, %edx
    je    L13
    leal    -13(%edx), %eax
    cmpl    $2, %eax
    ja    L3
    addl    $105, %edx
L3:
    popl    %ebp
    movl    %edx, %eax
    ret
    .p2align 4,,7
L11:
    popl    %ebp
    movl    $110, %edx
    movl    %edx, %eax
    ret
    .p2align 4,,7
L12:
    popl    %ebp
    movl    $112, %edx
    movl    %edx, %eax
    ret
    .p2align 4,,7
L13:
    popl    %ebp
    movl    $114, %edx
    movl    %edx, %eax
    ret

从这段汇编码来看，if语句是逐个判断下来的，如果i = 19的话，程序需要从头判断到尾，"一个都不能少"^_^。那么拥有同样语义功能的switch代码又是如何实现的呢？我们继续看下去。
// testswitch.c 这个文件实现的是和上述testif.c同样的功能
int test_switch_performance(int i) {
        int rv = i;

        switch(rv) {
                case 10:
                        rv += 100;
                        break;
                case 11:
                        rv += 101;
                        break;
                case 12:
                        rv += 102;
                        break;
                case 13:
                case 14:
                case 15:
                        rv += 105;
                        break;
                default:
                        rv += 0;
        }
        return rv;
}

我们同样用-O2来得到switch的汇编代码：
//gcc -S O2 testswitch.c
//testswitch.s
… …
_test_switch_performance:
    pushl    %ebp
    movl    %esp, %ebp
    movl    8(%ebp), %ecx
    leal    -10(%ecx), %edx
    movl    %ecx, %eax
    cmpl    $5, %edx
    ja    L2
    jmp    *L10(,%edx,4)
    .section .rdata,"dr"
    .align 4
L10:
    .long    L3
    .long    L4
    .long    L5
    .long    L8
    .long    L8
    .long    L8
    .text
    .p2align 4,,7
L8:
    leal    105(%ecx), %eax
    .p2align 4,,15
L2:
    popl    %ebp
    ret
    .p2align 4,,7
L3:
    popl    %ebp
    leal    100(%ecx), %eax
    ret
    .p2align 4,,7
L4:
    popl    %ebp
    leal    101(%ecx), %eax
    ret
    .p2align 4,,7
L5:
    popl    %ebp
    leal    102(%ecx), %eax
    ret
看完汇编码，第一感觉：cmpl少了许多，一个只读数据段中的L10的标签映入眼帘，以L10标签为起始的内存中依次存储了L3、L4、L5和三个L8的地址，看起来就像是一个地址数组，或者是一个地址表，访问这个数组中的元素实际上就是调用每个元素对应地址中的一段代码。我们继续往前看，来证实一下这个想法。代码不多，比对着汇编指令手册读起来也不甚难。

pushl    %ebp
movl    %esp, %ebp        // 将栈帧地址存在%ebp中
movl    8(%ebp), %ecx        // 将rv值存储到%ecx中
leal    -10(%ecx), %edx        // 将rv值-10之后的值，作为地址偏移量存放到%edx
movl    %ecx, %eax        // 将%ecx中的rv值存储到%eax中
cmpl    $5, %edx            // 比较5 vs. (rv – 10)，显然5是编译器经过代码扫描后，算出的一个最大偏移值
ja    L2            // jump if above ，如果5 > %edx中的值，则跳到L2继续执行
jmp    *L10(,%edx,4)        // 如果5 <= %edx中的值，则jmp    *L10(,%edx,4)

解析一下jmp    *L10(,%edx,4)，按照书中所说，*L10(,%edx,4)应该对应一个叫indexed memory mode的模式，格式一般是base_address(offset_address, index, size)，含义就是base_address + offset_address + index * size；这样似乎就一目了然了。我们拿i = 12为例，经过前面的计算，%edx中存储的是2，L10(,%edx,4)相当于L10 + 0 + 2 * 4，也就是起始地址=L10 + 8的那个内存区域，恰好是L5的起始地址，jmp    *L10(,%edx,4)，直接将代码执行routine转到L5了：

L5:
    popl    %ebp
    leal    102(%ecx), %eax
    ret
显然这和前面的猜测是一致的，switch并没有使用性能低下的逐个cmpl的方式，而是形成了一个跳转表(以L10为首地址的地址数组)，并将传入switch的那个整型值经过已经的运算后作为offset值，通过一个jmp直接转到目的代码区，这样无论switch有多少个分支，实际上都只是做了一次cmpl，性能照比多if有很大提升。