标签 C99 下的文章

也谈C语言的Struct Hack

今天在浏览网友huangz编写的“Redis源码分析”时,看到如下redis中的代码:

struct sdshdr {
    int len;
    int free;
    char buf[];
};

说实话,这类代码我见过很多,但直到这次我才知道这种coding trick的真实英文称谓是:Struct Hack。

到底什么是Struct Hack?其实倒也没有什么明确定义。首先它是一种coding trick;其次一定是与struct相关的;关键是struct中要仅有一个变长的字段,且该字段是struct中最后的一个字段,就像上面 sdshdr中的buf那样。这样的coding trick到底有何作用呢?

我们来看看redis中是如何利用这种coding trick的。sds是redis string的一种实现,全称是Simple Dynamic Strings,从字面意义来看,这是一种动态字符串,是可以在运行时确定其大小并创建的。我们来看看其创建代码:

typedef char *sds;

sds sdsnewlen(const void *init, size_t initlen) {
    struct sdshdr *sh;

    if (init) {
        sh = zmalloc(sizeof(struct sdshdr)+initlen+1);
    } else {
        sh = zcalloc(sizeof(struct sdshdr)+initlen+1);
    }

    if (sh == NULL) return NULL;

    sh->len = initlen;
    sh->free = 0;

    if (initlen && init)
        memcpy(sh->buf, init, initlen);
    sh->buf[initlen] = '\0';

    return (char*)sh->buf;
}

sdsnewlen在分配内存时,一次分配的内存大小不仅仅是sizeof(struct sdshdr),而是加上了真正存储字符串的buf的大小,并将buf作为返回值返回,sds就是buf,buf就是sds。这样通过sdshdr实例, 我们可以直接获得其对应的sds,也就是buf。更为关键的一点是,如果我已知sds,我们还可以获得其对应的sdshdr(huangz在文中称 sdshdr是sds handler的缩写,我倒是觉得hdr更像是header的缩写),见下面代码:

static inline size_t sdslen(const sds s) {
    struct sdshdr *sh = (void*)(s-(sizeof(struct sdshdr)));
    return sh->len;
}

这种trick给代码带来的极大的效率。想象一下如果redis的sdshdr定义是这样的:

struct sdshdr {
    int len;
    int free;
    char *buf;
};

/*  sdsnewlen */
struct sdshdr *sh;
sh = zmalloc(sizeof(struct sdshdr));
memset(sh, 0, sizeof(*sh));
sh->buf = zmalloc(initlen+1);

看起来似乎也能在运行时实现buf的动态size指定,但sdshdr与sds之间的纽带就被彻底割裂了(当然你也可以在 malloc sh时将buf内存也一并分配出来,然后手工将buf指向struct外的内存首地址,不过一旦这么做,就显得不那么tricky了)。

另外这里要探讨的是最后那个字段buf,是声明为buf[]好,还是buf[0]好,又或是buf[1]呢?redis使用的是buf[],在C99中这 是绝对合法的,这种定义被称为variable-length arrays(变长数组)。由于下标为空,这里的buf就好像是一个占位符,只有符号意义,但却并不实际占用空间。32bit平台下 sizeof(struct sdshdr) = 8,显然没有buf的份儿。不过在C99以前的标准中,是不允许变长数组出现的,你的Gcc很可能出现如下警告:“ISO C90 不允许可变数组成员”。不过C99以前很多编译器的扩展默认都是支持变长数组的,这也是这种trick之前就大行其道的原因之一,只不过是在C99之后变 得名正言顺了罢了。

如果将buf[]改为buf[0]呢?在C99以及支持变长数组扩展的编译器下也都是等同于buf[]的,不过C99以前的标准编译器还是会警告:ISO C 不允许大小为 0 的数组‘buf’ [-pedantic]。

用buf[1]替代buf[]则是一个兼容性最好的方案。在一些其他开源代码中,你也会常见buf[1]这种情形,如果以redis hds代码为例,我们用buf[1]替代buf[0]:

struct sdshdr {
    int len;
    int free;
    char buf[1];
};

相应的,sdsnewlen的代码以及sdslen中通过sds获取sdshdr的代码就应该做相应的修改了,简要修改如下:

/* sdsnewlen */

sds sdsnewlen(const void *init, size_t initlen) {
    struct sdshdr *sh;

    if (init) {
        sh = zmalloc(sizeof(struct sdshdr) – 1 + initlen + 1);
    } else {
        sh = zcalloc(sizeof(struct sdshdr) – 1 + initlen + 1);
    }

    if (sh == NULL) return NULL;

    sh->len = initlen;
    sh->free = 0;

    if (initlen && init)
        memcpy(sh->buf, init, initlen);
    sh->buf[initlen] = '\0';

    return (char*)sh->buf;
}


static inline size_t sdslen(const sds s) {
    struct sdshdr *sh = (void*)(s-(offsetof(struct sdshdr, buf)));
    return sh->len;
}

注意:使用这种coding trick为的就是获得一种运行时的动态行为,struct的大小也是动态的(这种struct的声明是一种incomplete type),所以这种struct都是在堆上分配内存的,在栈上分配显然是没有标准可移植的方法的;同样,由于是size不确定的incomplete type,这种struct一般不用于声明struct数组。

也谈C应用安装包制作与部署

虽然部门一直在做C应用,但这么多年来,在C应用的安装包制作以及部署方面做得还是很初级,可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样,水平参差不齐:有些产品的源码包即是安装包,把源码包拿到生产环境下编译后使用;有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中,在生产环境下重新链接生成可执行文件;有的组则稍微专业一些,安装包中放的是编译好的可执行文件,但在目标主机上安装和执行时也都遇到了一些问题,诸如运行环境中的第三方库版本号与程序所依赖的不一致等。

去年年底,我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容,这里也简单地谈谈。

总的来说,摆在我们面前的有三个主要问题:
1、安装包的组织方式不规范,不统一;
2、安装包的制作方式不规范,不统一;
3、安装包的部署方法不规范,不统一;

好了,下面我们就来针对上述问题逐一说说改进思路(注意以下内容并非普适)。

一、安装包组织方式
在Linux平台上应用的标准安装包是rpm或deb,但这种安装包形式似乎不太适合我们这种C后台应用。我对rpm或deb安装包了解的不多,但印象中这类安装包的安装一般为完全安装,但我们的应用升级版本时多数为增量安装或局部替换,因此做成rpm或deb虽然看起来专业一些,但实际操作起来并不灵活,因此自定义的安装包组织方式似乎更符合我们的需求。

下面是一个安装包的组织结构样例:
INSTALL_PACKAGE/
      – install.sh
      – README
      – app/
           – foo-1.0.1*
      – env/
           – conf/
           – log/
           – bin/
           …
      – deps/
           – libs/
              – bar/
           – tools/
      – scripts/
           – deps_check.sh
           – …
      – others/

其中:
app目录下存放的是可执行文件;
env目录下存放的是可执行程序运行时所需要的目录结构,包括配置文件等;
deps目录下存放的是可执行程序运行时所依赖的第三方库以及一些工具;
scripts目录下存放的是安装包安装过程中所需要的辅助脚本;
others目录下可以存放无法在上述目录下存放的其他数据;
install.sh是总控安装脚本,可以用于在目标主机上安装app、完整安装运行时环境、安装依赖libs或工具,执行scripts下面的必要脚本。

这样的一种安装包格式比较灵活,我们可以根据需要通过install.sh安装可执行文件或某个配置文件或其他数据文件。将INSTALL_PACKAGE目录打包(.tag.gz or .zip)就得到了我们的安装包。

安装包命名是要符合一定规范的,也便于进行配置管理。一个典型的安装包命名规范:程序名-版本号-平台-操作系统-编译模式.tar.gz[.zip],例如:
foo-1.8.3-x86-linux-64bit.tar.gz
bar-2.9.3-x86-solaris-32bit.tar.gz
zoo-1.3.2-sparc-solaris-64bit.zip

二、安装包的制作方式
以往的安装包都是直接基于项目源码库构建出来的,很多运行时目录、配置文件以及辅助脚本也都与源代码存放在一起,这样一来让源码库看起来很臃肿,二来一份源码控制无法对应部署到多个不同客户现场的安装包,也就是说不同客户生产环境下的配置、数据等都是不同的,但源码库只有一个,我只能保存一份配置,因此在生成不同安装包是似乎要临时修改,且无法将这些修改做版本管理。

我的一个想法就是将安装包涉及到的相关文件和目录从源码库中剥离出来,针对每个项目源码,我都会建立若干个安装包工程,安装包则是这些工程(project)的产物,且可以针对不同客户做有针对性的安装包修改和版本管理。记得Microsoft的Visual Studio就有单独的安装包制作工程模板,这里也算借鉴Visual Studio中安装包工程的思想了^_^。

下面是一个安装包工程的示例:
foo_INSTALL_Proj/
      – Makefile
      – distributions/
         – foo-2.9.3-x86-linux-64bit.tar.gz
      – src/
         – install.sh
         – README
         – app/
         – env/
           – conf/
           – log/
           – fifo/
           – bin/
           …
         – deps/
           – libs/
           – tools/
         – scripts/
           – deps_check.sh

         – others/
其中src下面的内容就是上面提到的安装包的组织,通过安装包工程我们就可以灵活控制安装包中的每一个元素,而对源码没有任何影响。

三、安装包的安装模式
有了前面两个问题解决作为铺垫,这个问题就很好办了。我们的应用大致有两种安装模式:本地安装和远程安装,实际上也是一回事。本地安装就是手工将安装包放在某个目标主机上,然后解压,并利用安装包中的install.sh来安装需要的文件;而远程安装多半是用远程控制工具将安装包上传到目标主机(可能是多台),并通过远程命令在远程主机上执行本地安装。

这里想到的一个改进就是在目标环境中部署应用前,首先执行一次部署约束检查,检查目标环境是否满足新应用部署和运行的约束条件。这在以前的部署步骤中是没有的,约束检测脚本可随安装包携带,比如放在scripts目录下。

总之,规范化的安装包组织形式、制作方式以及部署方式不仅是一种专业化的表现,它与一些自动化工具的结合还会促进团队或组织整体效率的提升

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系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