今天一位网上的朋友在使用reviewboard时遇到了问题，我们在评论中探讨了一下。他的问题目前已经定位，大致是这样的：他在Windows上用svn diff生成的patch文件在提交给reviewboard时出错，但在linux上生成的patch文件是没有问题的。后来他发现这两个patch文件内容稍有区别：Windows上的patch文件中的diff结果包含中文，比如“版本 10”；而在linux下生成的那份patch文件中，"版本 10"变成了"revision 10"。reviewboard拒绝了带中文的那份patch，估计是reviewboard的字符编码设置让其无法识别windows下的那个字符集。

多数情况下，我们根本无需关心svn命令输出中到底是英文还是中文。subversion对国际化支持到很好，它会根据自己所在环境下的区域和语言设置来选择到底输出哪种文字，对不同地区说不同语言的程序员来说，这绝对是一个好事。

但问题毕竟是出现了。我们该如何解决呢？我们该如何选择svn输出的语言呢？我不用Windows，所以这里我说说Linux下的设置方法，这也是今天在思考那位朋友的问题时才找到的方法。

方法的关键就在于前面说过的Subversion会自动检测你的区域和语言环境设置。以我的Ubuntu 12.04LTS为例，执行locale命令，可以看到以下输出：

LANG=zh_CN.UTF-8
LANGUAGE=zh_CN:zh
LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_PAPER="zh_CN.UTF-8"
LC_NAME="zh_CN.UTF-8"
LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"
LC_MEASUREMENT="zh_CN.UTF-8"
LC_IDENTIFICATION="zh_CN.UTF-8"
LC_ALL=

也就是说默认情况下，我的区域是CN，语言是zh。在这种环境下svn命令的输出都是包含中文的，比如下面这段输出：

路径: .
URL: https://lcut.googlecode.com/svn/trunk
版本库根: https://lcut.googlecode.com/svn
版本库 UUID: 22405a7c-d843-be82-cc3b-46f1d7cb9705
版本: 57
节点种类: 目录
调度: 正常
最后修改的作者: bigwhite.cn@gmail.com
最后修改的版本: 57

我尝试修改locale。先将LC_ALL修改为en_US.UTF-8（通过locale -a你可以查看系统支持的locale列表，从中能看到en_US.utf8）。修改后(export LC_ALL=en_US.utf8)，执行locale，发现除了LANGUAGE和LANG还是原值外，其余变量都已经改为en_US.utf8了。不过svn info的输出结果依旧包含中文。

看来LANGUAGE或LANG两个变量中的一个会影响到svn的输出结果。先修改LANG为en_US.utf8，执行svn info，发现结果依旧包含中文。再试试修改LANGUAGE，export LANGUAGE=en_US.en（注意不是en_US.utf8，LANGUAGE变量的值与其他的变量稍有不同）。再执行svn info，这回终于等到英文结果输出了：

Path: .
URL: https://lcut.googlecode.com/svn/trunk
Repository Root: https://lcut.googlecode.com/svn
Repository UUID: 22405a7c-d843-be82-cc3b-46f1d7cb9705
Revision: 57
Node Kind: directory
Schedule: normal
Last Changed Author: bigwhite.cn@gmail.com
Last Changed Rev: 57

目前还不清楚这招在Windows下是否也生效，记得Windows上也有设置环境变量的地方。

今天在浏览网友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数组。