GCC

上午在做一个Solaris 10 on x86代码移植测试过程中，发现一个Gcc编译问题，这里记录下来以作备忘。 我们的代码在一台安装了Solaris 10 for x86平台的机器A上进行64位编译(gcc -m64)时报错，错误信息如下： ...

前不久某南方省份的客户反馈说我们的产品对某些生僻字(如“赟”)的转码支持的不好，终端收到后无法显示这个字。 经分析，发现类似“赟”这样的字在GB2312编码标准中并未收录，要想支持这样的生僻字的内码转换需要产品支持目前最新的中文编码标准GB18030。而我们的产品在诞生到现在就一直只支持GB2312，这就是导致这一问题的直接原因。 ...

今天是冬至，也是入冬以来感觉最冷的一天，毫不夸张的说：你一张嘴，牙就冻上了。上午LP在家收拾卫生，我继续用Scons改造现有的项目。下午出去理发，头发长长了后，似乎会造成思维迟钝^_^。 试验性的用Scons改造现有的project，过程中对Scons了解又多了一些。上篇文章对Scons的性能没有给出定论，经过对Scons的深入后，发现Scons在执行初始时的性能的确不够快，这是因为Scons启动后，会对全部SConstruct以及下面子目录中的SConscript进行分析，子目录越多Sconscript文件个数越多，性能也就越差。但是这种分析也有一个优点，就是能帮你提前发现你SConscript中的一些“语义”错误，比如如果你在编译两个基础库，一个叫add，一个叫sub，这个基础库源码分别分布在两个目录add和sub中，编译后将分别生成libadd.a和libsub.a的库文件，但是如果你马虎了，在编写SConscript时将target都写成了’add’或都写成了’sub’，则Scons会在执行gcc之前就帮你找出这个"语义"错误，提示如下： /export/home1/tony_bai/xxlib>scons -f SC*t scons: Reading SConscript files … scons: *** Multiple ways to build the same target were specified for: /export/home1/tony_bai/xxlib/lib/libsub.a (from [’/export/home1/tony_bai/xxlib/add/libsub.a’] and from [’libsub.a’]) File “/export/home1/tony_bai/xxlib/sub/SConscript”, line 3, in ...

发现或者说知道SCons是缘于Google的comp.lang.c group上的一则名为"Best Build Tool for large C projects “的帖子，帖子的作者列出了11条他认为"Best Build Tool"应该具备的特点，并欲找到这样的Build Tool。在该帖子的回复中，有人提到了Scons，说来惭愧，这是我第一次听说到有这样一个工具。一直在Unix下编写C程序，习惯了Make，也对Make的复杂度和较为陡峭的学习曲线有所了解，曾经尝试使用Autoconf和Automake，但是都因上手困难而放弃。自己心底也一直想找到一个更简单一些的但又不失功能的适合C的Build Tool，Scons是否能满足的需要的呢？好奇心驱使着我去发掘一下Scons。 ...

今天闲时写了一个Demo测试程序，目的：测试64位编译下使用mmap映射共享内存的能力。程序很简单，大致如下结构： #define MAP_SPACE_SIZE (4*1024*1024*1024) unsigned long int ms_sz = MAP_SPACE_SIZE; …. …. ptr = mmap( NULL, ms_sz, PROT_READ|PROT_WRITE,MAP_SHARED, fd, 0 ); ...

最近在思考改进项目中一模块的实现，该模块维护起来让我很是头疼，所有才有了整体换掉它的想法。设计和实现中利用了内存对齐的技术。关于内存对齐，我曾经写过三篇文章，第一篇介绍了计算内存对齐的方法和例子，第二篇说了一个内存对齐的应用；三谈内存对齐时，则从其本质上做了阐述，而这次实际上是继续在其本质上的做文章，结合本质谈谈为什么内存对齐的计算方法就应该是第一篇中所讲的那两条。 如果对内存对齐本质还不清楚的话，就看看我的内存对齐系列的第三篇吧。如果你清楚了本质，那么我们结合第一篇中交待的内存对齐计算方法来进一步探究，为什么计算的方法就是这个样子的。 ...

随着工程代码量的增加，往往完整的编译一次Proj消耗的时间可能足够你喝两杯咖啡了，我现在build一次我所在proj的代码需要5分多钟，这是很痛苦的，颇让人懊恼的。为了解决这个工作中的别扭事儿，我在网上搜寻了一番，找到了distcc这个分布式编译工具。 ...

我所在的项目一直以C语言作为主要开发语言，与做Java以及其他新兴语言的人不同，组内的同事似乎对新鲜的东西不是那么感兴趣，也没有主动去研究新鲜事物的意愿和意识。我深为此闹心，看到外面世界中那么多美妙的工具，再也不能坐以待毙了。我一直都是有很多想法的，但是迫于自身精力有限，自己无法全身投入，以前都是交予别人去做的，但是收到的效果都不是很好。认识到这点后，我决定自己动手，丰衣足食。 ...

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

assert是大家常用的宏，它的用法相信大家都有所了解。P.J Plauger的"The C Standard Library"一书中提到在源代码中切换assert宏定义的方法： /* turn assertion on */ #undef NDEBUG #include ...