这个简单的方法只是创建一个动态大小为n的数组，并使用值0 ... n-1对其进行初始化。它包含一个错误，malloc（）只分配n而不是sizeof（int）* n bytes：
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);
}
当您检查输出时，您将看到它将按预期打印一些数字，但最后一些是乱码。但是，一旦我在循环中插入printf（），输出就是奇怪的正确，即使分配仍然是错误的！ 是否存在与printf（）相关的某种内存分配？
答案 0 :(得分：4)
严格地说，要回答标题中的问题，答案是它取决于实施。某些实现可能会分配内存，而其他实现可能不会。
虽然您的代码中存在其他固有问题，我将在下面详细说明。
注意：这最初是我对这个问题所做的一系列评论。我认为评论过多，并将他们转移到这个答案。
当您检查输出时，您将看到它将按预期打印一些数字，但最后一些是乱码。
我相信使用分段内存模型的系统，分配是＆＃34;四舍五入＆＃34;到一定的大小。即如果你分配X字节，你的程序确实会拥有那些X字节，但是，你也能够（错误地）超过这些X字节运行一段时间，然后CPU注意到你违反了界限和发送SIGSEGV。
这很可能是您的程序在特定配置中崩溃的原因。请注意，您分配的8个字节仅覆盖sizeof (int)为4的系统上的两个整数。其他6个整数所需的其他24个字节不属于您的数组，因此任何内容都可以写入该空间，以及何时如果您的程序没有首先崩溃，那么你会从那个空间读到，你会变得垃圾。
数字6很重要。请记住它以供日后使用！
神奇的部分是生成的数组内部会有正确的数字，printf实际上只是打印另一个数字。但这确实改变了阵列。
注意：以下是推测，我也假设你在64位系统上使用glibc。我要添加此内容，因为我觉得它可能有助于您了解可能出现的可能原因，但实际上是不正确的。
它是如何神奇地纠正＆＃34;最有可能与printf通过va_args接收这些数字有关。 printf可能正好填充了数组物理边界之外的内存区域（因为vprintf正在分配内存以执行＆＃34; itoa＆＃34;打印i所需的操作）。换句话说，那些＆＃34;正确＆＃34;结果实际上只是垃圾而且看起来是正确的＃34;但实际上，这恰好是在RAM中发生的事情。如果您在保留8字节分配的同时尝试将int更改为long，则您的程序将更有可能崩溃，因为long超过int。
malloc的glibc实现有一个优化，它在每次堆耗尽时从内核分配整个页面。这使得它更快，因为它不是要求内核在每次分配时获得更多内存，而是可以从＆＃34; pool＆＃34;中获取可用内存。并制作另一个＆＃34; pool＆＃34;当第一个填满时。
也就是说，像堆栈一样，来自内存池的malloc堆指针往往是连续的（或者至少非常靠近）。这意味着printf对malloc的调用可能会出现在为int数组分配的8个字节之后。然而，无论它是如何工作的，重点是无论如何正确＆＃34;结果可能看起来，它们实际上只是垃圾而你正在调用未定义的行为，因此无法知道将要发生什么，或者程序是否会在不同情况下做其他事情，如崩溃或产生意外行为。
所以我尝试使用和不使用printf运行你的程序，两次，结果都是错误的。
# without printf
$ ./a.out
0 1 2 3 4 5 1041 0
无论出于何种原因，没有任何内容干扰持有2..5的记忆。但是，有些东西干扰了持有6和7的记忆。我的猜测是这是vprintf的缓冲区，用于创建数字的字符串表示。 1041将是文本，0将是空终止符'\0'。即使它不是vprintf的结果，某些东西也会在填充和数组打印之间写入该地址。
# 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
这是有趣的部分。你的问题中没有提到你的程序是否崩溃。但当我跑它时，它崩溃了。的硬
与valgrind一起检查也是个好主意，如果有的话。 Valgrind是一个有用的程序，报告你如何使用你的记忆。这是valgrind的输出：
$ 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)
如您所见，valgrind报告您有invalid write of size 4和invalid read of size 4（4个字节是我系统中int的大小）。它还提到你正在读取一个大小为0的块，它是在一个8号块（你是malloc＆d; d）的块之后。这告诉你，你要经过阵列进入垃圾场。您可能会注意到的另一件事是它从2个上下文中生成了12个错误。具体而言，写入上下文中的 6 错误和阅读上下文中的 6 错误。正是我之前提到的未分配空间的数量。
以下是更正后的代码：
#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的输出：
$ 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)
请注意，它报告没有错误，结果是正确的。
答案 1 :(得分：3)
printf()是否在执行其工作的过程中分配任何内存是未指定的。如果任何给定的实现都这样做，那就不足为奇了，但是没有理由认为它确实如此。此外，如果一个实现确实如此，那就说明不同的实现是否有效。
当printf()在循环内部时，您会看到不同的行为。程序通过超出已分配对象的边界来展示未定义的行为。一旦这样做，所有后续行为都是未定义的。你不能推理未定义的行为，至少不是C语义。一旦未定义的行为开始，程序就没有 C语义。这是＆＃34; undefined＆＃34;装置
答案 2 :(得分：0)
您为数组分配了8个字节，但是存储了8个int，每个字节至少有2个字节（可能是4个字节），所以您要写入已分配内存的末尾。这样做会调用未定义的行为。
当您调用未定义的行为时，任何事情都可能发生。您的程序可能会崩溃，它可能会显示意外的结果，或者它似乎可以正常工作。看似无关的变化可能会改变上述哪种行为。
修复内存分配，代码将按预期工作。
int *result = malloc(sizeof(int) * n);