printf（）是否在C中分配内存？

这个简单的方法只是创建一个动态大小为n的数组，并用值0初始化它。。。n-1。它包含一个错误，malloc（）只分配n个字节，而不是sizeof（int）*n个字节：

int *make_array(size_t n) {
    int *result = malloc(n);

    for (int i = 0; i < n; ++i) {
        //printf("%d", i);
        result[i] = i;
    }

    return result;
}

int main() {
    int *result = make_array(8);

    for (int i = 0; i < 8; ++i) {
        printf("%d ", result[i]);
    }

    free(result);
}

int*生成数组（大小）{
int*result=malloc（n）；
对于（int i=0；i

当您检查输出时，您将看到它将按预期打印一些数字，但最后一个数字是乱七八糟的。然而，一旦我在循环中插入printf（），输出就出奇地正确，即使分配仍然是错误的！

---

是否存在与printf（）相关联的某种内存分配？

您为数组分配了8个字节，但您存储了8个

int

，每个字节至少有2个字节（可能是4个），因此您正在写入已分配内存的末尾。这样做会调用未定义的行为

当您调用未定义的行为时，任何事情都可能发生。您的程序可能会崩溃，可能会显示意外的结果，也可能看起来工作正常。一个看似不相关的改变可以改变上述哪种行为的发生

修复内存分配，代码将按预期工作

int *result = malloc(sizeof(int) * n);

未指定

printf（）

是否在执行其工作的过程中分配任何内存。如果任何给定的实现都这样做，这并不奇怪，但没有理由假设它会这样做。此外，如果一个实现执行了，那么这并不能说明另一个实现是否执行

---

当

printf（）

在循环中时，您看到的不同行为不会告诉您任何事情。程序通过超出已分配对象的边界而表现出未定义的行为。一旦这样做了，所有后续行为都是未定义的。您不能对未定义的行为进行推理，至少不能从C语义的角度进行推理。一旦未定义的行为开始，程序就没有C语义。这就是“未定义”的含义。

严格地说，要回答标题中的问题，答案是它取决于实现。一些实现可能会分配内存，而其他实现可能不会

尽管您的代码中还存在其他固有的问题，我将在下面详细说明

---

注意：这最初是我对这个问题的一系列评论。我觉得评论太多了，于是把他们转移到这个答案上来。

---

当您检查输出时，您将看到它将按预期打印一些数字，但最后一个数字是乱七八糟的

我相信在使用分段内存模型的系统上，分配是“四舍五入”到一定大小的。也就是说，如果您分配X字节，您的程序将确实拥有这些X字节，但是，在CPU发现您违反了边界并发送SIGSEGV之前，您还可以（错误地）运行这些X字节一段时间

这就是为什么您的程序在特定配置中没有崩溃的原因。请注意，在

sizeof（int）

为4的系统上，您分配的8个字节将只包含两个int。其他6个整数所需的其他24个字节不属于您的数组，因此任何东西都可以写入该空间，当您从该空间读取时，如果您的程序没有首先崩溃，您将得到垃圾

数字6很重要。以后记得

神奇的是，生成的数组中会有正确的数字，printf实际上只是每隔一次打印一个数字。但这确实改变了阵列

# with printf
$ ./a.out
*** Error in `./a.out': free(): invalid next size (fast): 0x0000000000be4010 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f9e5a720725]
/lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f9e5a728f4a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f9e5a72cabc]
./a.out[0x400679]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f9e5a6c9830]
./a.out[0x4004e9]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:02 1573060                            /tmp/a.out
00600000-00601000 r--p 00000000 08:02 1573060                            /tmp/a.out
00601000-00602000 rw-p 00001000 08:02 1573060                            /tmp/a.out
00be4000-00c05000 rw-p 00000000 00:00 0                                  [heap]
7f9e54000000-7f9e54021000 rw-p 00000000 00:00 0 
7f9e54021000-7f9e58000000 ---p 00000000 00:00 0 
7f9e5a493000-7f9e5a4a9000 r-xp 00000000 08:02 7995396                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f9e5a4a9000-7f9e5a6a8000 ---p 00016000 08:02 7995396                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f9e5a6a8000-7f9e5a6a9000 rw-p 00015000 08:02 7995396                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f9e5a6a9000-7f9e5a869000 r-xp 00000000 08:02 7999934                    /lib/x86_64-linux-gnu/libc-2.23.so
7f9e5a869000-7f9e5aa68000 ---p 001c0000 08:02 7999934                    /lib/x86_64-linux-gnu/libc-2.23.so
7f9e5aa68000-7f9e5aa6c000 r--p 001bf000 08:02 7999934                    /lib/x86_64-linux-gnu/libc-2.23.so
7f9e5aa6c000-7f9e5aa6e000 rw-p 001c3000 08:02 7999934                    /lib/x86_64-linux-gnu/libc-2.23.so
7f9e5aa6e000-7f9e5aa72000 rw-p 00000000 00:00 0 
7f9e5aa72000-7f9e5aa98000 r-xp 00000000 08:02 7999123                    /lib/x86_64-linux-gnu/ld-2.23.so
7f9e5ac5e000-7f9e5ac61000 rw-p 00000000 00:00 0 
7f9e5ac94000-7f9e5ac97000 rw-p 00000000 00:00 0 
7f9e5ac97000-7f9e5ac98000 r--p 00025000 08:02 7999123                    /lib/x86_64-linux-gnu/ld-2.23.so
7f9e5ac98000-7f9e5ac99000 rw-p 00026000 08:02 7999123                    /lib/x86_64-linux-gnu/ld-2.23.so
7f9e5ac99000-7f9e5ac9a000 rw-p 00000000 00:00 0 
7ffc30384000-7ffc303a5000 rw-p 00000000 00:00 0                          [stack]
7ffc303c9000-7ffc303cb000 r--p 00000000 00:00 0                          [vvar]
7ffc303cb000-7ffc303cd000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
012345670 1 2 3 4 5 6 7 Aborted

注意：以下是推测，我还假设您在64位系统上使用glibc。我之所以要添加这一点，是因为我觉得这可能有助于您理解某些内容看似正常，但实际上却不正确的可能原因。

它“神奇地正确”的原因很可能与

printf

通过va_args接收这些数字有关

printf

可能正在填充刚刚超过阵列物理边界的内存区域（因为vprintf正在分配内存以执行打印

i

所需的“itoa”操作）。换句话说，那些“正确”的结果实际上只是“看起来是正确的”垃圾，但实际上，这正是RAM中发生的事情。如果在保持8字节分配的同时尝试将

int

更改为

long

，则程序更可能崩溃，因为

long

比

int

长

malloc的glibc实现有一个优化，每次用完堆时，它都从内核分配整个页面。这使得它更快，因为它不需要在每次分配时向内核请求更多内存，而只需要从“池”中获取可用内存，并在第一个“池”填满时创建另一个“池”

也就是说，与堆栈一样，来自内存池的malloc堆指针往往是连续的（或者至少非常接近）。这意味着printf对malloc的调用很可能出现在为int数组分配的8个字节之后。然而，不管它是如何工作的，关键是无论结果看起来多么“正确”，它们实际上只是垃圾，您正在调用未定义的行为，因此无法知道将发生什么，或者程序是否会在不同的情况下执行其他操作，例如崩溃或产生意外行为

---

所以我试着在有printf和没有printf的情况下运行你的程序，两次结果都是错误的

# without printf
$ ./a.out 
0 1 2 3 4 5 1041 0 

无论出于何种原因，都不会干扰内存保持

2..5

。但是，某些东西干扰了存储

6

和

7

。我猜这是vprintf的缓冲区，用于创建字符串REPRESS

$ valgrind ./a.out
==5991== Memcheck, a memory error detector
==5991== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5991== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==5991== Command: ./a.out
==5991== 
==5991== Invalid write of size 4
==5991==    at 0x4005F2: make_array (in /tmp/a.out)
==5991==    by 0x40061A: main (in /tmp/a.out)
==5991==  Address 0x5203048 is 0 bytes after a block of size 8 alloc'd
==5991==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5991==    by 0x4005CD: make_array (in /tmp/a.out)
==5991==    by 0x40061A: main (in /tmp/a.out)
==5991== 
==5991== Invalid read of size 4
==5991==    at 0x40063C: main (in /tmp/a.out)
==5991==  Address 0x5203048 is 0 bytes after a block of size 8 alloc'd
==5991==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5991==    by 0x4005CD: make_array (in /tmp/a.out)
==5991==    by 0x40061A: main (in /tmp/a.out)
==5991== 
0 1 2 3 4 5 6 7 ==5991== 
==5991== HEAP SUMMARY:
==5991==     in use at exit: 0 bytes in 0 blocks
==5991==   total heap usage: 2 allocs, 2 frees, 1,032 bytes allocated
==5991== 
==5991== All heap blocks were freed -- no leaks are possible
==5991== 
==5991== For counts of detected and suppressed errors, rerun with: -v
==5991== ERROR SUMMARY: 12 errors from 2 contexts (suppressed: 0 from 0)

#include <stdio.h>
#include <stdlib.h>

int *make_array(size_t n) {
    int *result = malloc(n * sizeof (int)); // Notice the sizeof (int)

    for (int i = 0; i < n; ++i)
        result[i] = i;

    return result;
}

int main() {
    int *result = make_array(8);

    for (int i = 0; i < 8; ++i)
        printf("%d ", result[i]);

    free(result);
    return 0;
}

$ valgrind ./a.out
==9931== Memcheck, a memory error detector
==9931== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9931== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==9931== Command: ./a.out
==9931== 
0 1 2 3 4 5 6 7 ==9931== 
==9931== HEAP SUMMARY:
==9931==     in use at exit: 0 bytes in 0 blocks
==9931==   total heap usage: 2 allocs, 2 frees, 1,056 bytes allocated
==9931== 
==9931== All heap blocks were freed -- no leaks are possible
==9931== 
==9931== For counts of detected and suppressed errors, rerun with: -v
==9931== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)