标签 GNU 下的文章

Go defer的C实现

Go语言中引入了一个新的关键字defer,个人认为这个语法关键字让异常处理也变得得心应手许多,对改善代码的可读性和可维护性大有裨益,是典型的语法棒棒糖^_^。

像下面这种代码(伪代码):

void foo() {
    apply resource1;

    retv = action1;
    if not success
        release resource1

    apply resource2;

    retv = action2;
    if not success
        release resource1
        release resource2
}

有了defer后,代码就变得优美多了。

void foo_with_defer() {
    apply resource1;
    defer (release_resource1)

    retv = action1;
    if not success
        return

    apply resource2;
    defer (release_resource2)

    retv = action2;
    if not success
        return
}

如果能在C语言中实现defer这样的语法糖,那该多棒!是否可行呢?经过一段时间钻研,找到一个不那么美的实现方法,约束也很多,也不甚严谨, 谈不上什么可移植性,切不可用到产品环境,权当一种探讨罢了。

Go中defer的语义大致是这样的:
* 在使用defer的函数退出前,defer后面的函数将会被执行;
* 如果一个函数内有多个defer,那么defer按后进先出(LIFO)的顺行执行;
* 即使发生Panic,defer依然可以得到执行

最后一个比较难于模拟,这里仅先尝试前两个语义。下面从设计思路说起。

* “借东风”

要想模拟defer,首先要考虑的一点那就是defer后的语句是在函数return之前执行的。在标准C中,我们无任何举措可以实现这些。要在 C中实现defer,势必要借用一些编译器扩展特性,比如Gcc的扩展。这里实验所使用的编译器是Gcc(4.6.3 (Ubuntu 12.04))。Gcc扩展支持-finstrument-functions编译选项,该选项可以在函数执行前后插入一段运行代码。在之前写过的一篇名 为“为函数添加enter和exit级trace”的文章中对此有较为详细的说明,这里我们还要用到这个扩展特性。

* 偷天换日

如果完全模仿Go的语法,在C中使用defer,大致是这样一种形式:

void foo(void) {
    FILE * fp = NULL;
    fp = fopen("foo.txt", "r");
    if (!fp) return;
    defer(fclose(fp));
   
    /* use fp */
    … …
    return;
}

但C毕竟是C,一门静态的编译型语言,我们如何将fclose(fp)这个信息传递给编译器自动插入的代码中呢?在C语言中,几乎没有手段获得函 数的元信息以及运行时参数信息,并再通过这些信息重新调用和执行该函数。我们得“想招”将这些信息存储起来。

大家知道C语言中的函数,比如这里的fclose,其实是一个函数起始地址;如果我们知道函数地址或又叫函数指针,再加上函数的参数,我们就可以 拼凑在一起执行该函数了。但理论上来说,函数指针也是有类型的,比如:

typedef int (*FUNC_POINTER)(int, int);

这个函数指针类型可以用来执行诸如:int foo(int a, int b)这样的函数,比如:

FUNC_POINTER fp = foo;
fp(1, 2);

但defer后面执行的函数千差万别,我们如何能够得知函数对应的函数指针类型呢?用void*存储?比如:

void *p = foo;
p(1, 2);

编译器会给你一个严重错误!p不是函数指针,不能这么用。那我们如何能让编译器知道这个指针是一个可调用的函数指针呢?我们试试来定义一个“通用 的函数指针”:

typedef void (*defer_func)();

没有返回值,没有参数,这样的函数指针能否执行foo这样的函数呢?答案是可以的,但不是那么完美。至少你不会得到返回值。这么做有两点考虑:
a) 至少可以让编译器知道这是一个函数指针,可以被用来执行函数。
b) 通常我们并不关心defer后面函数的返回值。
c) 参数列表的不同至少目前可以逃过编译器的错误检查,至多给个Warning。

函数指针的问题暂时算是有着落了,那参数怎么办?也就是说defer(fclose(fp))中的fp如何存储下来呢?如果在C中真的使用 defer(fclose(p))这种形式的语法,那么我是砸破脑袋也想不出啥招了!因此我们应该重新设计一下C中的defer应该如何使用?我 们用下面的语法来替代:

defer(fclose, 1, p);

fclose是函数起始地址,1是参数个数,p则是传给fclose的参数。这样fclose和p都可以单独分离出来存储了。但是还是那句 话:defer后面可以执行的函数千万种,哪能穷尽?怎么才能表示成一种通用的方式存储参数呢?回想一下自己在编码过程中用于释放资源的那几类函 数,无非就是关闭文件、关闭文件描述符(包括socket)、释放内存等,这些函数传递的参数不是指针就是整型数,少有传浮点类型或将一个自定义 结构体以传值的方式传入的。我们不妨再次尝试一次“偷天换日” – 用void*存储整型参数或任意指针类型参数。当然其约束就像刚才所说的那些。不过对付大多数资源释放函数而言,应该是足够的了。至于将参数个数也作为一 个固定参数放入defer中,也是鉴于目前无法通过操作可变个数参数列表相关宏来获得参数数量。

最后一个问题。由于被defer的函数的参数个数不定。defer无法将可变个数参数重组后传给被defer的函数。因此目前暂只能通过一种“丑陋”的方式来实现。样例中最多只支持两个参数的被defer函数。

* 样例

首先看看我们的examples的主函数文件main.c。

#include <stdio.h>
#include <stdlib.h>
#include "defer.h"

int bar(int a, char *s) {
    printf("a = [%d], s = [%s]\n", a, s);
}

int main() {
    FILE *fp = NULL;
    fp = fopen("main.c", "r");
    if (!fp) return;
    defer(fclose, 1, fp);

    int *p = malloc(sizeof(*p));
    if (!p) return;
    defer(free, 1, p);

    defer(bar, 2, 13, "hello");
    return 0;
}

从这里我们可以看到defer的用法,但这不是重点,重点是实现。

有了上面的一些设计思路的阐述,下面的代码也就不难理解了。核心是defer.c。
/* defer.h */
typedef void (*defer_func)();

struct zero_params_func_ctx {
    defer_func df;
};

struct one_params_func_ctx {
    defer_func df;
    void *p1;
};

struct two_params_func_ctx {
    defer_func df;
    void *p1;
    void *p2;
};

struct defer_func_ctx {
    int params_count;
    union {
        struct zero_params_func_ctx zp;
        struct one_params_func_ctx op;
        struct two_params_func_ctx tp;
    } ctx;
};

void stack_push(struct defer_func_ctx *ctx);
struct defer_func_ctx* stack_pop();
int stack_top();

/* defer.c */
struct defer_func_ctx ctx_stack[10];
int top_of_stack = 0; /* stack top from 1 to 10 */

void stack_push(struct defer_func_ctx *ctx) {
    if (top_of_stack >= 10) {
        return;
    }

    ctx_stack[top_of_stack] = *ctx;
    top_of_stack++;
}

struct defer_func_ctx* stack_pop() {
    if (top_of_stack == 0) {
        return NULL;
    }

    top_of_stack–;
    return &ctx_stack[top_of_stack];
}

int stack_top() {
    return top_of_stack;
}

void defer(defer_func fp, int arg_count, …) {
    va_list ap;
    va_start(ap, arg_count);

    struct defer_func_ctx ctx;
    memset(&ctx, 0, sizeof(ctx));
    ctx.params_count = arg_count;

    if (arg_count == 0) {
        ctx.ctx.zp.df = fp;

    } else if (arg_count == 1) {
        ctx.ctx.op.df = fp;
        ctx.ctx.op.p1 = va_arg(ap, void*);

    } else if (arg_count == 2) {
        ctx.ctx.tp.df = fp;
        ctx.ctx.tp.p1 = va_arg(ap, void*);
        ctx.ctx.tp.p2 = va_arg(ap, void*);
        ctx.ctx.tp.df(ctx.ctx.tp.p1, ctx.ctx.tp.p2);
    }

    va_end(ap);
    stack_push(&ctx);
}

多个defer的FIFO调用顺序用一个固定大小的stack来实现。这里只是为了演示,所以stack实现的简单和固定些。

组装后的函数在funcexit.c中执行:

extern struct defer_func_ctx ctx_stack[10];

__attribute__((no_instrument_function))
void __cyg_profile_func_exit(void *this_fn, void *call_site) {
    struct defer_func_ctx *ctx = NULL;

    while ((ctx = stack_pop()) != NULL) {
        if (ctx->params_count == 0) {
            ctx->ctx.zp.df();
        } else if (ctx->params_count == 1) {
            ctx->ctx.op.df(ctx->ctx.op.p1);
        } else if (ctx->params_count == 2) {
            ctx->ctx.tp.df(ctx->ctx.tp.p1, ctx->ctx.tp.p2);
        }
    }
}

最后我们将defer.c、funcexit.c编译成一个.so文件:

gcc -g -fPIC -shared -o libcdefer.so funcexit.c defer.c

而编译main.c的方法如下:

gcc -g main.c -o main -finstrument-functions -I ../lib -L ../lib -lcdefer

一切OK后,先将libcdefer.so放在main同级目录下,执行main即可。

$> ./main
a = [13], s = [hello]

具体代码已经传至这里(trunk/cdefer),需要的童鞋可自行下载。 

将Unity换成Gnome3

Ubuntu 12.04已经体验一天多了,Unity还是用的不大习惯,左侧的程序启动栏感觉还是别扭,以前用windows的时候就不喜欢将任务栏放在左侧或右侧; 应用窗口的菜单栏融合到桌面顶端也没给我太多惊喜;总而言之,给自己找几个换回Gome的理由还是很容易的^_^。况且Gnome也发生了巨变, 由传统的Gnome2更新到了全新的Gnome3,正好我也想体验一下Gnome3,于是继续折腾。

 
Ubuntu 12.04.1官方源里就有Gnome3,因此只需执行sudo apt-get install gnome-shell即可安装Gnome3。Gnome3还有一个高级配置工具,可以执行sudo apt-get install gnome-tweak-tool安装。安装后注销,在登录窗口选择Gnome桌面即可。
 
Gnome3默认桌面十分简洁,除了左上角的“活动”之外,别无它物。据说Unity也是基于Gnome开发的,只是比Gnome3多了一个左侧 程序启动栏(虽然也可以隐藏,但试过,感觉十分不灵敏)。我并未删除Unity,主要是担心删除后可能会给系统带来不稳定性。
 
点击“活动”后展现的界面我还是蛮喜欢的:中间是所有打开的窗口缩略图,左边是应用收藏夹,与Unity左侧的程序启动栏类似。右侧是半隐藏的 “工作区”栏。最下方是隐藏了主界面的程序的图标栏,该栏是自动隐藏的,将鼠标指针放到屏幕右下角时,该栏会出现。另外通过Win快捷键可以直接 打开“活动”主界面,十分方便。“活动”界面中的搜索框还可以作为程序启动器来用。
 
Gnome3默认取消了窗口中的最大、最小化按钮,不过利用gnome-tweak-tool这个高级配置工具可以恢复最大、最小化按钮:打开 tweak工具,找到shell -> arrangement of buttons on the titlebar,选择all即可。
 
Gnome3的切换窗口快捷键Alt + Tab将相同程序的不同窗口叠加在一起,这个我不甚喜欢,还得动用方向键选择,我更喜欢所有窗口不分类别的平铺。对于处理这种折叠窗口的情况,我更喜欢用 Win键打开“活动”界面,然后在上面选择我需要的窗口。
 
Gnome3窗口最大化的快捷键为“ctrl + win + 上箭头”,但我还没发现最小化的快捷键。
 
Gnome3的文件管理器左侧的快捷方式边栏似乎不能像Gnome2那样自定义快捷方式,这样无法快速访问常用的一些文件夹。
 
Gnome3的体验暂且就是这些,后续还待慢慢挖掘。
 
另外这两天还针对Ubuntu 12.04做了一些改造:
 
* 用Clipit替换Parcellite
 
我的Parcellite启动后,无法在提示栏显示出小图标,无法对其进行配置,也就无法做剪切板的同步。后安装了Clipit,它是 Parcellite的一个分支,功能与Parcellite一致。用apt-get install即可。
 
* 安装OpenJDK
 
本想安装Oracle提供的JDK的,但无奈从Oracle提供的链接下载太慢,只能以OpenJDK替代。据说Oracle后续JDK也是基于 OpenJDK的,只是额外加上了一些私有代码。
 
sudo apt-get install openjdk-7-jre openjdk-7-jdk
 
$ java -version
java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.04.1)
OpenJDK Client VM (build 23.2-b09, mixed mode, sharing)
 
* SunPinyin配置
 
SunPinYin默认不支持逗号和句号键翻页,执行/usr/lib/ibus-sunpinyin/ibus-setup- sunpinyin可以重新配置翻页键;同理用/usr/lib/ibus-pinyin/ibus-setup-pinyin也可以对默认携带 的拼音输入法进行设置。 

做正确的事要趁早

最近闲暇时间在策划实施两件事儿:一是产品的自动化回归测试;二是尝试在项目中使用一些静态代码语义分析工具。我觉得这两件事是应该做的正确的事,对提升产品质量,提前发现产品中潜在的缺陷都大有裨益。但在做的过程中才感觉到:现在做有些晚,正确的事要趁早做。

去年自动化测试组发布了自动化测试框架的第一个版本,我们的产品参加了试点。但经过自动化测试组大半年的投入,效果十分有限,根本没有达到我的预期。最主 要的问题是使用他们提供的框架编写和维护test case都十分困难,工作量投入很大,这很打击大家的积极性。今年大家决定将自动化测试框架换成nokia开源的robotframework。经过预 研,robotframework完全可以满足我们的测试需求,并且robotframework的用例编写和维护效率太高了,编写门槛却很低。

虽然换成了robotframework,但我们应用的时机还是有些晚了。试点项目已经接近开发尾声,这时候如果要加上自动化测试,势必就要在短时间进行 大量测试用例开发。如果在项目初期,增量的用例添加相信会达到更好的效果。但即便是“亡羊补牢”,我们也还是要做的,还好这个产品版本的生命周期才刚刚开 始,后续可能还会持续很多年,加上自动化回归测试还是有重大意义的。

不过鉴于之前的教训,我们调整了自动化测试的切入点。之前自动化测试组只是闷头写用例,并未太多考虑自动化测试框架与被测目标如何配合的问题:比如没有考 虑自动化测试在哪个环节应用、谁来驱动、谁来执行以及测试环境如何生成等。这次我们先绕过用例编写,先从“基础设施”搭建开始。我们的目标是将自动化测试 与我们的持续集成流程集成在一起,也就是说我们将通过jenkins这样的ci平台来作为自动化回归测试的驱动。我们首先就是要将这个驱动流程run起 来,即便测试用例库中一条用例也没有。一旦run起来后,我们再将关注点集中在用例的编写和调试上,我想这才是正确的思路。

第二件感觉做得有些晚的正确的事儿就是为项目增加静态代码检查环节。之前项目静态代码检查仅停留在打开GCC编译器的-Wall选项这个层次。就是否有必 要引入第三方静态代码分析工具对代码进行缺陷检查,大家一直没有统一意见。质量部门希望我们引入,但关键问题是我们没有找到一款适合的开源工具(for C),在维基提供的C语言静态分析工具列表中,我感觉似乎只有splint符合我们的要求 – 开源、功能强大且支持linux/unix。不过splint似乎已经停止开发了,最新版本停留在3.1.2。

使用类似splint这样的工具对代码进行检查时总是能给出大量的warning,如果不加以控制,那么屏幕就会被warning淹没。因此正式使用之 前,需要一个“磨合期”。先确定打开或关闭哪些检查规则开关,原则只有一个,即尽量避免误警告,又不能漏掉真实的隐患。splint对C99新增语法的支 持不是很好。splint碰到下面这种语法时会提示parse error,并且无法recover:

struct foo {
    int a;
    int b;
};

int main() {
    struct foo f = {.a = 1, .b = 2};  /* Parse Error */
    printf("%d %d\n",  f.a,  f.b);
    return 0;
}

这类静态代码检查的基础设施在项目初期搭建起来是最佳的,开发人员可以增量的对代码进行语义检查,并修正缺陷。但如果在代码开发即将结束的阶段加入,即使 是设置了一套合理的检查规则组合,你也可能困惑于工具产生的大量Warning。不过“有胜于无”,在没有找到更好的工具前,我将splint加入到工程 中,建议组员适当时机使用,并随时对check rules组合开关进行调整和优化。也许经过一段时间的磨合后,可以实现在ci job中加入自动代码静态检查这个环节,当然目前肯定不是适宜时间。

正确的事,你会发现早做和晚做效果是截然不同的。但“亡羊补牢“的工作也不能不做。既然是你认为正确的事,从长远来看,还是能带来很大价值的。




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

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

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多