今天在项目中使用snprintf时遇到一个比较迷惑的问题，追根溯源了一下，在此对sprintf和snprintf进行一下对比分析。

因为sprintf可能导致缓冲区溢出问题而不被推荐使用，所以在项目中我一直优先选择使用snprintf函数，虽然会稍微麻烦那么一点点。这里就是sprintf和snprintf最主要的区别：snprintf通过提供缓冲区的可用大小传入参数来保证缓冲区的不溢出，如果超出缓冲区大小则进行截断。但是对于snprintf函数，还有一些细微的差别需要注意。

snprintf函数的返回值

sprintf函数返回的是实际输出到字符串缓冲中的字符个数，包括null结束符。而snprintf函数返回的是应该输出到字符串缓冲的字符个数，所以snprintf的返回值可能大于给定的可用缓冲大小以及最终得到的字符串长度。看代码最清楚不过了：

上述代码段的输出结果如下：

所以在使用snprintf函数的返回值时，需要小心慎重，避免人为造成的缓冲区溢出，不然得不偿失。

snprintf函数的字符串缓冲

上面的函数原型大家都非常熟悉，我一直以为snprintf除了多一个缓冲区大小参数外，表现行为都和sprintf一致，直到今天遇上的bug。在此之前我把下面的代码段的两个输出视为一致。

可实际上得到的输出结果却是:

知其然就应该知其所以然，这是良好的求知态度，所以果断翻glibc的源代码去，不凭空想当然。下面用代码说话，这就是开源的好处之一。首先看snprintf的实现：

使用_IO_vsnprintf函数实现：

关键点出来了，源文件第117行string[0] = ‘\0‘;把字符串缓冲先清空后才进行实际的输出操作。那sprintf是不是就没有清空这个操作呢，继续代码比较中，sprintf的实现：

使用_IO_vsprintf而不是_IO_vsnprintf函数，_IO_vsprintf函数实现：

在40行到42行之间没有进行字符串缓冲的清空操作，一切了然。

一开始是打算使用gdb调试跟踪进入snprintf函数探个究竟的，可是调试时发现用step和stepi都进不到snprintf函数里面去，看了一下链接的动态库，原来libc库已经stripped掉了：

所以只能去找 ftp://ftp.gnu.org/gnu/glibc官网啃源代码了。

在找glibc源码时，我想知道系统当前使用的glibc版本，一时不知道怎么查，Google一下大多数都是Redhat上的rpm查法，不适用于Ubuntn，而用dpkg和aptitude show都查不到glibc package，后来才找到ldd用法。

现在才发现Ubuntn用的是好像是EGLIBC，而不是标准的glibc库。其实上面ldd snprintf_test查看应用程序的链接库的方法可以更快速地知道程序链接的glibc版本。