也谈C语言应用构建
构建是软件开发过程中最常见的活动之一,也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言,其历史已甚为悠久了(相对于还年轻的IT领域^_^)。从C语言诞生以来,市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千,从最简单的单个源文件,到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源码组织形态如何,构建都是这些应用开发过程中必不可少的一步。 ...
构建是软件开发过程中最常见的活动之一,也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言,其历史已甚为悠久了(相对于还年轻的IT领域^_^)。从C语言诞生以来,市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千,从最简单的单个源文件,到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源码组织形态如何,构建都是这些应用开发过程中必不可少的一步。 ...
在Unix/Linux上,我们一般可以通过两种方法查看到一个可执行程序的版本信息,以下以Ubuntu中的Gcc为例。 第一种方法:我们可以直接通过程序名字得到版本信息,例如: $ which gcc /usr/bin/gcc $ ls -l /usr/bin/gcc lrwxrwxrwx 1 root root 7 2010-08-21 00:18 /usr/bin/gcc -> gcc-4.4* ...
至今我还记得第一次听说C99标准还是在读大一时,那时同寝一位兄弟手头有一本Herbert Schildt编写的《C: The Complete Reference,Fourth Edition》(中文名:C语言大全),书封皮的右上角上赫然写着"详解C99 ANSI/ISO最新标准",那时离C99标准发布仅仅才一年。 ...
了解C编译器的工作流程有助于C程序员解决编译代码过程中出现的问题。市面上凡是讲解得还算全面的C语言书籍中都或多或少对此有所提及。 让我们在这里来回顾一下C编译器的工作流程!一般C编译器的工作流程大致分为:预编译、编译、生成目标代码(汇编)和连接这四个主要步骤。我们用实例具体描述一下这四个步骤,以最著名的GCC编译器结合helloworld.c文件为例: ...
C99 原生支持布尔类型,类型名字为_Bool。对C程序员来说,这个名字有些“不伦不类”,还好一般C标准库 实现的头文件中都用宏bool来替代_Bool。C99虽说是C语言当前的最新标准,但是它也有10年历史之久了。据说C1x标准 正在讨论制定中,有兴趣的朋友可以到标准C工作组 官方站点上去瞧瞧。 ...
上午对一段代码进行单元测试,由于需要用到mock,所以选择使用cmockery 作为Unit Testing框架(lcut还未提供mock功能)。测试代码里需要mock malloc以模拟分配内存失败的异常情况。 编写一个用例后,Build,提示出错:multiple definition of `malloc’。经检查发现Makefile中定义mock malloc的那个目标文件(.o文件)居然被link了两次,类似于下面的这种错误情形: $ gcc testmain.c malloc.o malloc.o malloc.o: In function `malloc’: malloc.c:(.text+0×0): multiple definition of `malloc’ malloc.o:malloc.c:(.text+0×0): first defined here collect2: ld returned 1 exit status ...
昨天看了“外刊IT评论”上的一篇名为《软件编程21法则》的文章,文章中提到的一条法则是:“软件直到被变成产品运行至少6个月后,它最严重的问题才会被发现”,当时表示认同。不过仅仅相隔一天,这条法则就变成了眼前的现实。 今天上午我们的某版本系统在某省出现了故障,该版本在这个省上线恰好将近6个月^_^,系统上线以来一直运行良好,直到这次故障。故障现象为"挂死":所有进程都挂死在某一把锁的lock上。以前出现这种情况多为某个进程加锁后,在锁内异常退出,未能释放锁而导致其他进程挂死。这种"挂死"多是代码中访问非法内存地址导致的,一般都会有core文件dump出来。不过这次出现挂死后,我们并未找到core文件的影子。查看系统运行日志也无果。通过脚本将所有该应用的子进程的运行栈快照收集到一个文件中,然后对这个数据庞大的文件进行分析,以试图找到一些蛛丝马迹。 ...
每当你Build Project代码的时候,如果看到的是满屏的Warning,那么提醒你小心了,不妨看看《高效程序员的45个习惯》中对Warning的态度和处理方式。该书中的第34个习惯讲的是“警告就是错误”! 当然这个“习惯”所阐述的内容并不是这本书首创,在很多经典的传授编程之道的书中也都提到过。 ...
今天闲时写了一个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 ); ...
最近在思考改进项目中一模块的实现,该模块维护起来让我很是头疼,所有才有了整体换掉它的想法。设计和实现中利用了内存对齐的技术。关于内存对齐,我曾经写过三篇文章,第一篇介绍了计算内存对齐的方法和例子,第二篇说了一个内存对齐的应用;三谈内存对齐时,则从其本质上做了阐述,而这次实际上是继续在其本质上的做文章,结合本质谈谈为什么内存对齐的计算方法就应该是第一篇中所讲的那两条。 如果对内存对齐本质还不清楚的话,就看看我的内存对齐系列的第三篇吧。如果你清楚了本质,那么我们结合第一篇中交待的内存对齐计算方法来进一步探究,为什么计算的方法就是这个样子的。 ...