标签 GCC 下的文章

使用C99特性简化代码编写

至今我还记得第一次听说C99标准还是在读大一时,那时同寝一位兄弟手头有一本Herbert Schildt编写的《C: The Complete Reference,Fourth Edition》(中文名:C语言大全),书封皮的右上角上赫然写着"详解C99 ANSI/ISO最新标准",那时离C99标准发布仅仅才一年。

那个时候我们大学授课以及实验用的还是Borland的Turbo C 2.0,C99标准根本无从谈起。转眼间十多年过去了,C99标准逐渐成熟,各大编译器厂商以及开源编译器都完善了自己的产品,对C99有了很好的支持,像Gcc编译器在最新的4.6版本里几乎完全支持所有C99特性。但如果你依旧在用Microsoft的Visual Studio,那么很遗憾你可能依旧无法使用C99的诸多新特性。

工作以来一直使用GCC作为C的编译器,但一直采用的是GCC的默认C标准,即gnu89,也就是C90标准加上一些GCC自行的扩展。直到去年年末与Dreamhead闲聊时,Dreamhead提出可利用C99标准简化代码编写的想法,我这才有意识地去主动了解一些有关C99与上一版标准不同的地方,并在今年的项目中尝试用gnu99(-std=gnu99)替代gnu89。

与上一版标准相比,C99做了几十处修订,可用于简化代码编写的新增特性虽然不多,不过大多都还算很实用,其中一些是GCC在自己的扩展中已经存在了多年的特性,这次也被正式纳入C99标准中了。

下面我就列举一些可以帮助你简化C代码编写的C99特性(也许还不够全面):

* 布尔类型
很多C程序员都很向往Java以及C#等语言中提供的原生bool类型,在C语言没有真正提供bool类型之前,很多C程序中都有这样的代码:

#undef  bool
#undef  true
#undef  false

typedef enum {
        false,
        true
} bool;

C99标准中正式引入了布尔类型_Bool,注意是_Bool而不是bool。虽然不是bool,而是一个对于类型名称而言有些丑陋的名字,但这也给C程序员带来了些许福音。C标准委员会显然也考虑到了大家的质疑,遂又为C99引入了一个标准头文件"stdbool.h",在该文件中我们看到了bool,true和false的定义,只不过它们不是原生的,而是宏:
#define bool    _Bool
#define true    1
#define false   0

即使是这样,我们依旧可以无需编写自己的bool类型了(不过如果考虑在不同版本编译器之间的移植的话,还是需要根据__STDC_VERSION__来选择到底使用内置bool还是自定义bool的)。

#include
bool found = true;
bool empty = false;
bool is_foo();
int xx_hash_create(xx_hash_t **h, bool shared);

或者用_Bool类型关键字:
/* no header needed */
_Bool found = 1;
_Bool empty = 0;
_Bool is_foo();
int xx_hash_create(xx_hash_t **h, _Bool shared);

* 可变参数宏
在不支持可变参数宏的日子里,我们经常这么定义一些宏:

#define compare2(compf, arg1, arg2) \
    compf(arg1, arg2)

#define compare3(compf, arg1, arg2, arg3) \
    compf(arg1, arg2, arg3)

#define compare4(compf, arg1, arg2, arg3, arg4) \
    compf(arg1, arg2, arg3, arg4)
… …

有了可变参数宏后,我们只需一个定义即可:
#define compare(compf, …) \
    compf(__VA_ARGS__)

compare(strcmp, "hello", "world");
compare(triplestrcmp, "hello", "world", "foo");
… …

* Compound Literals
这个特性比较难于译成中文,直译起来就是"复合字面量"。其实它类似一个匿名变量,其语法形式为"(类型){初始值列表}",下面是一些例子可以帮助你理解:

在没有"Compound Literals"特性之前,我们可以这样编写代码:
struct xx_allocator_t allocator;
allocator.af = malloc;
allocator.ff = free;
xx_hash_new(.., &allocator);

使用C99特性,我们就可以省掉xx_hash_new之前的那个变量定义和初始化了:
xx_hash_new(.., &(struct xx_allocator_t){.af = malloc, .ff = free});

* Designated initializers(指定初始化器)
在没有这个特性之前,我们在用初始化器初始化一个数组或者一个结构体时,一般要给所有元素都赋值:

struct foo {
    int a;
    char b;
    char s[20];
};

int a[5] = {1, 2, 3, 4, 5};
struct foo f = {1, 'A', "hello"};
struct foo v[3] = {
    {1, 'A', "hello"},
    {2, 'B', "hi"},
    {3, 'C', "hey"}
};

如果我们只想为数组中某一个元素赋值,或者为结构体中某一个字段赋值的话,我们就不能使用初始化器了,只能这样来做:
int a[5];
a[2] = 3;

struct foo f;
strcpy(f.s, "hello");

struct foo v[3];
v[1].a = 2;
v[1].b = 'B';
strccpy(v[1].s, "hi");

C99给我们带来了指定初始化器的特性,我们可以在初始化时指定为哪个结构体字段或数组元素赋值:

int a[5] = {[2] = 3, [4] = 5};

struct foo f = {.s = "hello"};
struct foo v[3] = {
    [1] = {.a = 2, .b= 'B', .s = "hi"}
};

* 为选择与迭代语句引入新的块范围
这个C++程序员定然不陌生,在C++中我们可以这样定义一个循环:
for (int i = 0; i < 100; i++) {
    … …
}

但在老版本C中,我们只能这样做:
int i;
for (i = 0; i < 100; i++) {
    … …
}

不过使用C99后,你就可以和C++程序员同等待遇了。

和近几年涌现的一些新语言相比,古老的C语言中可以用于简化代码编写的语法糖就显得少得有些可怜。C1x标准目前正在制定中,但也不要对C1x期望太高,毕竟C语言的精髓并非旨在改善开发效率。

偿还N年前的一笔技术债

记得刚来公司时曾参与过一个项目,项目中用到了部门基础库中的一个B+树接口。不过在程序调试过程中我们发现可执行程序总是dump core(在sparc solaris上),经初步分析,断定问题就出在B+树接口处,但一时又找不到问题原因。还好这个B+树的实现者就坐在我的旁边。他分析后告诉我:这个B+树接口要求用户自定义的索引结构体的size应该为4的整数倍。按照他的说法,我为结构体打了padding,以满足结构体size为4的整数倍的要求。修改后果然不再dump core了。当时项目进度紧,我也没有求甚解,这件事也就过去了。

一晃N年过去了。今天在做程序的64位移植过程中我再次遇到了这个问题。问题的表象就是程序运行时dump core,通过gdb或pstack查看core的内容,发现程序是在B+ Tree初始化时出的core。显然这又是一个内存违规访问的问题,且在Sparc上出现(x86 Linux上运行正常)十有八九与内存对齐有关。

B+ Tree出问题首先让我想到了N年前的那个解决方法。我先查看了自定义的索引结构体(usr_idx):

struct usr_idx {
    unsigned int usr;
};

不过sizeof(usr_idx)无论是32bit编译还是64bit编译,其值都是4。那按照B+树原作者的说法,这显然不足以让B+树出现问题。事实也的确如此,32bit编译的程序在Sparc Solaris下运行良好,只是目前改为了64bit编译,才dump core,那问题到底出现在哪呢?

到这里,我也只能从代码着手了,把N年前没弄清楚的原因找出来,顺便也把这个存在了N年的Bug彻底解决掉,把这笔技术债还了。pstack的输出告诉我问题出在一个名为bptree_create_node的函数中,嫌疑最大的一处代码大致是这样的:

for (i = 0; i rank; i++) {
    (elem_base(tree, tmp_bn, i))->key = key_base(tree, tmp_bn, i);
    (elem_base(tree, tmp_bn, i))->pointer = NULL;
}

直觉告诉我问题出在elem_base这个宏里,elem_base的定义如下:

#define elem_base(tree, eb, index) ((xx_bptree_elem*)((char *)&(eb)->e_base.mw_cp + ((SIZEOF_bptree_elem + (tree)->keysize))*(index)))

很显然这个定义最终是想得到一个xx_bptree_elem*类型的指针。从内存地址角度来说,我们会得到了一个内存地址,且这个地址被认为是一个xx_bptree_element元素的起始地址。那么是否所有地址作为xx_bptree_element元素的起始地址都合法呢?答案是不一定,至少在Sparc平台上不是所有地址都可以作为xx_bptree_elem的起始地址的。

那么什么样地址可以作为xx_bptree_element的起始地址呢?在Sparc上这取决于结构体的对齐系数。xx_bptree_elem结构的定义如下:

union mem_word {
    void  *mw_vp;
    void (*mw_fp)(void);
    char  *mw_cp;
    long   mw_l;
    double mw_d;
};
typedef union mem_word mem_word;
#define SIZEOF_mem_word (sizeof(mem_word))

struct xx_bptree_elem {
    void       *key;
    void       *pointer;
    mem_word   base;
};
typedef struct xx_bptree_item xx_bptree_item;
#define SIZEOF_bptree_elem        (sizeof(xx_bptree_elem)-sizeof(mem_word))

在32bit编译的情况下,系统默认对齐系数为4(参见/usr/include/sys/isa_defs.h中的宏_MAX_ALIGNMENT),则该结构体的对齐系数 = min(max(sizeof(key), sizeof(pointer), sizeof(base)), 4) = 4。这样xx_bptree_elem在32bit下的有效起始地址为可被4整除的内存地址。

而在用64bit编译时,系统默认的对齐系数为16(同参见isa_defs.h),但由于xx_bptree_elem中size最大的字段(base)的size为8,则结构体的对齐系数就等于8。即xx_bptree_elem元素的有效起始地址为可被8整除的地址。

好了,我们再回过头来看看elem_base宏在不同编译情况下能否总是返回合法的地址。

#define elem_base(tree, eb, index) ((xx_bptree_elem*)((char *)&(eb)->e_base.mw_cp + ((SIZEOF_bptree_elem + (tree)->keysize))*(index)))

这个宏中有三个元素决定返回地址,分别是"基址":&(eb)->e_base.mw_cp、偏移量SIZEOF_bptree_elem和(tree)->keysize。其中基址是另外一个结构体xx_bptree_node中一个mem_word类型字段的地址,你知道的,mem_word这种手法可以保证其起始地址严格按照其内部最大字段的对齐系数对齐的,也就是说mem_word的对齐系数与double的对齐系数一致,即无论是32bit编译还是64bit编译,其对齐系数都是8,也就是说我们可以确保这个”基址“是可以被8整除的;至于偏移量SIZEOF_bptree_elem,我们可以直接可以得出其大小:

32bit下,SIZEOF_bptree_elem = 8
64bit下,SIZEOF_bptree_elem = 16

可以看出无论是32bit还是64bit编译,SIZEOF_bptree_elem的值都是8的倍数;显然这两个值都不会影响elem_base最终返回地址的合法性。

现在剩下的就是(tree)->keysize了。keysize是由xx_bptree_init接口传进来的,它在上层实际上就是用户自定义的索引结构体的大小,显然这个大小不一定就是8的倍数。在我们的系统中,keysize = sizeof(usr_idx) =
4。这个keysize在32bit编译下是没有问题的,因为32bit编译只需要elem_base返回的地址可以被4整除即可,这也是为什么我们的程序在32bit编译下运行正常的原因。回想一下N年前的那个问题,其真正原因也就在这里:当时我定义的索引结构体的大小无法被4整除。在64bit编译下,keysize显然不能满足被8整除的要求,导致elem_base返回的地址只能被4整除。而xx_bptree_elem这个结构体的地址是严格要求必须可被8整除的。将一个只能被4整除而不能被8整除的地址强制转换为xx_bptree_elem元素地址并通过该强制类型转换后的地址访问xx_bptree_elem内部的元素显然就会导致core的出现了。

现在看来当初我的同事并未真正理解该B+ tree为何要求用户自定义结构体的大小必须为4的整数倍了,他只是通过现象得到了那条经验罢了,这笔技术债务也就从那时留了下来。

解决该问题并不难,作为基础库,我们无论如何都不应该依赖用户的自觉,我们在接口实现中增加一个转换就可以解决这一隐藏了若干年的Bug,将外面传入的keysize经align_word转换后再赋给tree->keysize,这样就可以保证elem_base始终返回合法的地址了。

突然想起了那句话:”出来混,总是要还的“,我们欠的技术债务也不例外。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats