本文主要对带有 _s 的这类 安全 函数(如 memcpy_s)进行简单介绍，以及如何在自己的 Linux 开发环境中使用这些函数。
最近在写程序时，涉及内存拷贝的问题，比如我这里有三个字符类型数组 a、b、c，可以理解为三个缓冲区，其中 a 和 b 中的 内容需要根据 c 中的内容进行构建，a 取其中的前半段，b 取其中的后半段，需要取的长度已知。
显然，这里可以使用内存拷贝函数 memcpy。你知道从 c 缓冲区的那个地方开始，到哪里结束应该给 a 缓冲区和 b 缓冲区，使用 memcpy 进行定长拷贝，这种做法很便捷。但是，我却被同事告知这种做法不是很安全，应当使用 memcpy_s 函数来进行定长(内存)拷贝。那我心里就产生了一个疑问：为什么这些函数更加安全，标准库却没有引入呢？
随即，我发现不仅仅有 memcpy_s，还有很多类似的函数，如：strncpy_s、memmove_s、memset_s、snprintf_s、strcpy_s 等等，有这么一类函数的存在，他们被称之为 C 的安全库函数，但是却不在标准库中，标准库中的这些函数，都是不带有 _s 的。
这类所谓的安全函数最初是由微软( Microsoft )为 Windows 平台实现的，其官方名字为 Safe C Library，见其 ，这里有这些函数的详细介绍，以及函数实现的文件依赖图( Include dependency graph )。但是有很多组织机构是反对将这些纳入 C 标准库中的，尽管最终微软说服 C 标准委员会( C standard committee) 将这些函数加入附录 K 中，但是这些函数仍然不是标准库的一部分。这些安全函数从 C11 标准才开始支持，但似乎也仅限于 MSVC （微软的 VC 运行库）。以上，大概就能够解释为什么官方手册中给的示例程序在自己的 Linux 开发机中无法编译、运行，即便引入了 srting.h 头函数，即便你在程序中定义了文档中所说必须的宏，也还是会显示找不到 memcpy_s 函数的定义。如果你真的去查找了一遍，就会发现，string.h 文件中根本没有对应的这些函数。
至此，你可以理解为，这一类所谓更安全的函数，是微软的 VC 运行库中的函数，对于其他平台，默认并不支持，当今强制推广这些安全函数的只有 Windows 平台。（啊这，微软写的，自己不得给自己捧场。）
这里源码对比分析仅限于 memcpy 与 memcpy_s。
搞清楚了它的背景，来谈一下相比于标准库的这些函数，这些函数有什么改进的地方。
我们来拿 memcpy 函数与 memcpy_s 函数举例。先来看看 memcpy 函数的源码实现：
/* libgcc/memcpy.c */
#include <stddef.h>
void *
memcpy (void *dest, const void *src, size_t len)
{
char *d = dest;
const char *s = src;
while (len--)
*d++ = *s++;
return dest;
}
这里的源码来自 libgcc/memcpy.c, 不同地方的源码实现可能稍有差异(目前我见过三个版本，大同小异吧)，总体而言，memcpy 函数实现较为简单，并不会对指针是否合法、缓冲区长度是否满足拷贝的需要进行检查。再来看一下 memcpy_s 函数。memcpy_s 函数的实现如下：
#ifdef FOR_DOXYGEN
#include "safe_mem_lib.h"
#else
#include "safeclib_private.h"
#include "mem/mem_primitives_lib.h"
#endif
#if defined(TEST_MSVCRT) && defined(HAVE_MEMCPY_S)
#else
#ifdef FOR_DOXYGEN //这个宏是否定义决定是否实现这个函数
errno_t memcpy_s(void *restrict dest, rsize_t dmax,
const void *restrict src, rsize_t slen)
#else
EXPORT errno_t _memcpy_s_chk(void *restrict dest, rsize_t dmax,
const void *restrict src, rsize_t slen,
const size_t destbos, const size_t srcbos)
#endif
{
uint8_t *dp;
const uint8_t *sp;
/* MSVC 在最开始就进行检查，这里也这么做 */
if (unlikely(slen == 0)) { /* 从 C11 开始，允许slen = 0，即拷贝的长度可以是0，此时函数什么都不做 */
return EOK;
}
dp = (uint8_t *)dest;
sp = (uint8_t *)src;
/* 这里会检查指针是否指向 NULL、目的缓冲区是否为空 */
CHK_DEST_MEM_NULL("memcpy_s")
CHK_DMAX_MEM_ZERO("memcpy_s")
if (destbos == BOS_UNKNOWN) {
CHK_DMAX_MEM_MAX("memcpy_s", RSIZE_MAX_MEM)
BND_CHK_PTR_BOUNDS(dest, dmax);
BND_CHK_PTR_BOUNDS(dest, slen);
} else {
CHK_DEST_MEM_OVR("memcpy_s", destbos)
/* Note: unlike to memset_s, we don't set dmax to destbos */
}
CHK_SRC_MEM_NULL_CLEAR("memcpy_s", src)
CHK_SLEN_MEM_MAX_NOSPC_CLEAR("memcpy_s", slen, RSIZE_MAX_MEM)
if (srcbos == BOS_UNKNOWN) {
BND_CHK_PTR_BOUNDS(src, slen);
} else if (unlikely(slen > srcbos)) {
invoke_safe_mem_constraint_handler("memcpy_s: slen exceeds src",
(void *)src, EOVERFLOW);
return (RCNEGATE(EOVERFLOW));
}
/* 不允许重叠，但是允许源缓冲区和目的缓冲区的指针相同，即两个缓冲区的起始位置可以是一个地方，相当于什么都不做 */
if (unlikely(CHK_OVRLP_BUTSAME(dp, dmax, sp, slen))) {
mem_prim_set(dp, dmax, 0);
MEMORY_BARRIER;
invoke_safe_mem_constraint_handler("memcpy_s: overlap undefined", dest,
ESOVRLP);
return RCNEGATE(ESOVRLP);
}
/*
* 这里真正执行拷贝
*/
mem_prim_move(dp, sp, slen);
return RCNEGATE(EOK);
}
#ifdef __KERNEL__
EXPORT_SYMBOL(_memcpy_s_chk);
#endif
#endif
这里的源码来自 Safe C Library。不难看出，memcpy_s 函数在执行时，会先对两个缓冲区的大小，以及各自指针指向的位置是否合法、是否会产生重叠等进行检查，相对于 memcpy 函数， memcpy_s 函数可以帮助我们做一些检查，帮助我们发现程序中写出的错误。
memcpy_s 的检查功能在程序发布之前，可以说还是挺好的，编译程序时，一定程度上能帮助我们发现程序中的错误之处，这样我们可以及时对程序进行修正。我们自己没有发现的错误，可以让程序帮我们检查出来，自然要省一些事。但是最终程序能够正常运行而不出错，还是需要我们自己传入合法的指针、合法的长度。注意，这类’安全’函数的功能只是多做一些检查，而不是自己处理这些不合法的情况。这就意味着，它是用来辅助开发者写出问题尽可能少的代码。那如果说开发者已经借助各种工具、提示，写出问题尽可能少，工作也正常的程序，那这个时候，为了安全而进行的校验，反而显得有些多余。比如，初学者考驾照时都需要一个教练，教练会教你如何正确行驶，当你学会驾驶汽车之后，你的副驾位置就不需要一直有教练在了。
出于性能考虑，对于较大型的软件，可能使用这类函数(如内存拷贝)的地方很多，如果每个地方都需要使用到这些’安全’函数，反而会降低程序的执行效率，因为你要花费很多时间在各种校验上，在开发者尽可能去规避掉各种不合法情况之后，这些校验大部分都是不必要的。还需要注意的是，我前边说的是一定程度上，也就是说，这类函数的一些检查，并不一定能检查出所有的问题，仍然可能会有比较隐蔽的错误发生。这些大概能解释为什么会有很多反对将这些函数纳入 C 标准库吧。
吐槽归吐槽，你可能会鄙弃这些函数，但出于某种原因，你可能身不由己，还是需要去用这些东西。既然了解了，就顺便讲一下其他平台的使用这类函数的方法吧。
编译、安装都需要在 root 用户下进行。之后需要执行的命令分别如下所示：
# 这里已经是在 root 用户下，如果不是，则需要使用 sudo 执行
./build-aux/autogen.sh
./configure # 如果想自己指定安装位置，可以使用 --prefix=/path/to/install，通常默认安装位置在/usr/local目录下
make
make install
过程中如果出现 Libtool library used but ‘LIBTOOL’ is undefined，则可能是没有安装 libtool 工具。
当你看到 autoreconf: command not found这样的错误消息时，这通常意味着你的系统上没有安装 autoreconf 工具或者它没有被添加到你的系统路径中。autoreconf 是一个 GNU 工具，它用于更新和重新生成 configure 脚本和其他相关的自动工具文件，通常在编译源代码时用于配置和构建过程。为了解决这个问题，你可以按照以下步骤操作：
sudo apt-get update
sudo apt-get install autoconf automake libtool
sudo yum install autoconf automake libtool
到这里，已经是安装完成的状态了，这时候，我们可以尝试使用 memcpy_s 函数了。首先需要引入头文件 “safe_mem_lib.h” 。
#include <safe_mem_lib.h>
gcc test_memcpy_s.c -o test -I/usr/local/include/safeclib -I/usr/local/lib -lsafec
到这里，编译、链接程序生成可执行文件应该是没问题了，但是在运行可执行文件的过程中，可能会出现找不到动态库的问题，如下所示：
./test # 运行程序，得到如下结果，显示找不到libsafec.so.3
./test_c: error while loading shared libraries: libsafec.so.3: cannot open shared object file: No such file or directory
# 使用 ldd 查看程序所依赖的库的情况，执行结果如下
ldd test
linux-vdso.so.1 (0x0000ffffa0444000)
libsafec.so.3 => not found # 这里显示找不到这个库文件
libc.so.6 => /lib64/libc.so.6 (0x0000ffffa0248000)
/lib/ld-linux-aarch64.so.1 (0x0000ffffa0407000)
cd /usr/local/lib
ls
libsafec.a libsafec.la libsafec.so libsafec.so.3 libsafec.so.3.0.7 pkgconfig
对应解决办法如下：
# 首先打开 ld.so.conf 文件，并在文件中添加相应库所在的目录路径，即将 /usr/local/lib 添加到文件中，独占一行即可。注意需要 sudo 权限
sudo vim /etc/ld.so.conf
# 添加之后执行如下命令，注意也需要 sudo 权限
sudo ldconfig
# 之后检查程序是否能够找到相关的库，发现已经可以找到了
ldd test
linux-vdso.so.1 (0x0000ffff9ccde000)
libsafec.so.3 => /usr/local/lib/libsafec.so.3 (0x0000ffff9cc3c000)
libc.so.6 => /lib64/libc.so.6 (0x0000ffff9ca7d000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff9cca1000)
这里已经没有 not found 了，程序可以正常执行了。
这里简单的对 Safe C Library 进行了简单介绍，对于这一类含有 _s 的函数，我这里只是对比分析了其中一个，其余相关函数逻辑上大抵类似，但这样也许会以偏概全，还是希望开发者在实践中产生自己的理解。
每个人的开发环境，使用过程可能都会有差异，以上是在我环境中的部署情况以及遇到的问题，欢迎交流探讨。