使用C字符串时内存泄漏

我试图在C中构建str_replace函数（以便学习C）。为了让事情变得更简单，我决定创建两个助手函数，其中一个具有以下原型：

char*str\u shift\u right（const char*string，char fill，int32\n）

它接受一个字符串并将字符
fill
添加到给定字符串的
n
th位置。以下是完整的代码：

// replace the nth char with 'fill' in 'string', 0-indexed
char * str_shift_right(const char * string, char fill, int32_t n) {
    // +1 the null byte, +1 for the new char
    int32_t new_size = (int32_t) strlen(string) + 2;
    char * new_string = NULL;
    new_string = calloc(new_size, sizeof(char));

    new_string[new_size - 1] = '\0';
    int32_t i = 0;
    while (i < strlen(string) + 1) {
        // insert replacement char if on the right position
        if (i == n) {
            new_string[i] = fill;

        // if the replacement has been done, shift remaining chars to the right
        } else if (i > n) {
            new_string[i] = string[i - 1];

        // this is the begining of the new string, same as the old one
        } else {
            new_string[i] = string[i];
        }

        i++;
    }

    return new_string;
}

然而，当使用activity monitor（一个Mac OSX应用程序，对于那些不熟悉的人来说，有点像Windows上的进程管理器）观察内存使用情况时，RAM似乎很快就被占用了，当程序停止执行时，它就不可用了

这就是内存泄漏吗？如果是，我做错了什么？
free（new\u str）
调用不应该释放内存吗

谢谢你的帮助

编辑1：由PaulR发现的一个错误修复。问题仍然存在。
空闲
不应该向系统释放内存（例如，使用，因为
malloc
通常更喜欢重用以前的
空闲
-d内存，而不是从内核获取内存（例如，使用
mmap
）

直觉上，管理内存地址空间的系统调用（即
mmap
&
munmap
）非常昂贵，因此大多数
malloc
&
免费
实现尽可能在内部重用内存

如果您怀疑内存泄漏，请尝试（最新版本已移植到MacOSX）。当然，使用调试信息和所有警告编译代码（例如，
gcc-Wall-g
或可能
clang-Wall-g
）
更新：您是如何测量的？这在UNIX上不可能：“[memory]当程序停止执行时不可用。也许你只是看错了号码

我看不出哪里应该有内存。请尝试使用
valgrind
等工具

前面提到的无效写入已经讨论过很多次了。也许你正在用它破坏内存管理信息。我看到C库在每个分配的内存块之前和/或之后使用字节来跟踪分配的内存片段。因此，也许你是在用这种方式调零大小，削弱内存管理因此，实际上，使用
valgrind和类似的工具

但是，您可能还希望简化代码

无需将要完全覆盖的内存归零
当您已经知道位置时，无需使用循环
您还可以复制尾随的
\0
实际使用
size\u t
，它是无符号的。如果
fill
是负数，则上面的代码不会发出警告。对于
size\u t
它不能是负数
所以这应该足够了（我没有编译这个测试-您可能想要）：

最后一个
memcpy
也会在这里复制后面的
\0
。总的来说，C编译器可能会更好地优化此代码，
memcpy
通常会得到很好的处理。另外，它实际上更易于阅读

看起来RAM很快就被占用了，当程序停止执行时，它就不可用了

您正在查看哪种RAM使用情况？系统中的总RAM使用情况

如果是这样，您看到的可能是您的终端使用的内存–您的程序打印出的每个字符都将由终端存储在RAM中（尽管它可能会在某个限制下开始丢弃内容）。请重试，但这一次，请防止输出显示在终端中：

./program > /dev/null

作为一般规则，无论您泄漏了多少内存，当您的程序终止时，它都会自动释放。而且我无法发现您的程序中有任何泄漏。
虽然已经提到过，但我认为值得强调的是，如果您怀疑程序中有内存泄漏，不要仅仅通过观察系统m得出结论监视器，但改用valgrind

从这里下载：

为什么
calloc
当您立即写入所有的零时，它为您进行了如此完美的初始化？
new_string[new_size]='\0'；
是无效的写入-您可能是指
new_string[new_size-1]='\0'；
？您也可以使用类似
valgrind
的工具来检查您的程序是否存在内存泄漏。@PaulR:谢谢您的帮助！问题已经解决，但问题仍然存在。提示：如果您在MacOSX上开发，请查看XCode附带的应用程序。其中包含一些非常强大的内存调试工具。它应该重用分配的内存空间。所以，如果它“相当快地消耗内存”，那么这种重用不会像预期的那样工作。这是正确的，但我认为这与OP的体验无关。
char* str_shift_right(const char* string, char fill, size_t n) {
  size_t len = strlen(string);
  char* new_string = malloc(len + 2, sizeof(char));
  memcpy(new_string, string, n);
  new_string[n] = fill;
  memcpy(new_string + n + 1, string + n, len - n + 1);
  return new_string;
}

./program > /dev/null