C语言 内存基础

http://c.biancheng.net/

程序的运行

详细了解请自行学习《计算机组成原理》《汇编语言》。

寄存器（Register）是CPU内部非常小、非常快速的存储部件，它的容量很有限，对于32位的CPU，每个寄存器一般能存储32位（4个字节）的数据，对于64位的CPU，每个寄存器一般能存储64位（8个字节）的数据。为了完成各种复杂的功能，现代CPU都内置了几十个甚至上百个的寄存器，嵌入式系统功能单一，寄存器数量较少。

虚拟地址

我们在C语言中会使用&取址符来获取地址，该地址并不是真的，大致如下图所示：

虚拟地址的整个想法是这样的：把程序给出的地址看做是一种虚拟地址（Virtual Address），然后通过某些映射的方法，将这个虚拟地址转换成实际的物理地址。这样，只要我们能够妥善地控制这个虚拟地址到物理地址的映射过程，就可以保证程序每次运行时都可以使用相同的地址。

除了在编程时可以使用固定的内存地址，给程序员带来方便外，使用虚拟地址还能够使不同程序的地址空间相互隔离，提高内存使用效率。

使不同程序的地址空间相互隔离

如果所有程序都直接使用物理内存，那么程序所使用的地址空间不是相互隔离的。恶意程序可以很容易改写其他程序的内存数据，以达到破坏的目的；有些非恶意、但是有 Bug 的程序也可能会不小心修改其他程序的数据，导致其他程序崩溃。

这对于需要安全稳定的计算机环境的用户来说是不能容忍的，用户希望他在使用计算机的时候，其中一个任务失败了，至少不会影响其他任务。

使用了虚拟地址后，程序A和程序B虽然都可以访问同一个地址，但它们对应的物理地址是不同的，无论如何操作，都不会修改对方的内存。

提高内存使用效率

使用虚拟地址后，操作系统会更多地介入到内存管理工作中，这使得控制内存权限成为可能。例如，我们希望保存数据的内存没有执行权限，保存代码的内存没有修改权限，操作系统占用的内存普通程序没有读取权限等。

另外，当物理内存不足时，操作系统能够更加灵活地控制换入换出的粒度，磁盘 I/O 是非常耗时的工作，这能够从很大程度上提高程序性能。

以上两点我们将在《内存分页机制》和《内存分页机制的实现》中进行详细讲解。

虚拟地址是使用中间层的一个典型例子。

虚拟地址空间

虚拟地址空间，就是程序可以使用的虚拟地址的有效范围。

虚拟地址和物理地址的映射关系由操作系统决定，相应地，虚拟地址空间的大小也由操作系统决定，但还会受到编译模式的影响。

内存对齐，提高寻址效率

将一个数据尽量放在一个步长之内，避免跨步长存储，这称为内存对齐。

计算机内存是以字节（Byte）为单位划分的，理论上CPU可以访问任意编号的字节，但实际情况并非如此。

CPU 通过地址总线来访问内存，一次能处理几个字节的数据，就命令地址总线读取几个字节的数据。32 位的 CPU 一次可以处理4个字节的数据，那么每次就从内存读取4个字节的数据；少了浪费主频，多了没有用。64位的处理器也是这个道理，每次读取8个字节。

以32位的CPU为例，实际寻址的步长为4个字节，也就是只对编号为 4 的倍数的内存寻址，例如 0、4、8、12、1000 等，而不会对编号为 1、3、11、1001 的内存寻址。如下图所示：

这样做可以以最快的速度寻址：不遗漏一个字节，也不重复对一个字节寻址。

对于程序来说，一个变量最好位于一个寻址步长的范围内，这样一次就可以读取到变量的值；如果跨步长存储，就需要读取两次，然后再拼接数据，效率显然降低了。

例如一个 int 类型的数据，如果地址为 8，那么很好办，对编号为 8 的内存寻址一次就可以。如果编号为 10，就比较麻烦，CPU需要先对编号为 8 的内存寻址，读取4个字节，得到该数据的前半部分，然后再对编号为 12 的内存寻址，读取4个字节，得到该数据的后半部分，再将这两部分拼接起来，才能取得数据的值。

为了提高存取效率，编译器会自动进行内存对齐，请看下面的代码：

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

struct{
    int a;
    char b;
    int c;
}t={ 10, 'C', 20 };

int main(){
    printf("length: %d\n", sizeof(t));
    printf("&a: %X\n&b: %X\n&c: %X\n", &t.a, &t.b, &t.c);

    system("pause");
    return 0;
}

在32位编译模式下的运行结果：

length: 12
&a: B69030
&b: B69034
&c: B69038

如果不考虑内存对齐，结构体变量 t 所占内存应该为 4+1+4 = 9 个字节。考虑到内存对齐，虽然成员 b 只占用1个字节，但它所在的寻址步长内还剩下 3 个字节的空间，放不下一个 int 型的变量了，所以要把成员 c 放到下一个寻址步长。剩下的这3个字节，作为内存填充浪费掉了。请看下图：

编译器之所以要内存对齐，是为了更加高效的存取成员 c，而代价就是浪费了3个字节的空间。

除了结构体，变量也会进行内存对齐，请看下面的代码：

#include <stdio.h>
#include <stdlib.h>
int m;
char c;
int n;
int main(){
    printf("&m: %X\n&c: %X\n&n: %X\n", &m, &c, &n);
    system("pause");
    return 0;
}

在VS下运行：

&m: DE3384
&c: DE338C
&n: DE3388

可见它们的地址都是4的整数倍，并相互挨着。

对于全局变量，GCC在 Debug 和 Release 模式下都会进行内存对齐，而VS只有在 Release 模式下才会进行对齐。而对于局部变量，GCC和VS都不会进行对齐，不管是Debug模式还是Release模式。

内存分页机制

例如程序A需要 10MB 内存，虚拟地址的范围是从 0X00000000 到 0X00A00000，假设它被映射到一段同等大小的物理内存，地址范围从 0X00100000 到 0X00B00000，即虚拟空间中的每一个字节对应于物理空间中的每一个字节。

当程序A需要访问 0X00001000 时，系统会将这个虚拟地址转换成实际的物理地址 0X00101000，访问 0X002E0000 时，转换成 0X003E0000，以此类推。

这种以整个程序为单位的方法很好地解决了不同程序地址不隔离的问题，同时也能够在程序中使用固定的地址。

-
地址隔离

如上图所示，程序A和程序B分别被映射到了两块不同的物理内存，它们之间没有任何重叠，如果程序A访问的虚拟地址超出了 0X00A00000 这个范围，系统就会判断这是一个非法的访问，拒绝这个请求，并将这个错误报告给用户，通常的做法就是强制关闭程序。

-
程序可以使用固定的内存地址

虚拟内存无论被映射到物理内存的哪一个区域，对于程序员来说都是透明的，我们不需要关心物理地址的变化，只需要按照从地址 0X00000000 到 0X00A00000 来编写程序、放置变量即可，程序不再需要重定位。

-
内存使用效率问题

以程序为单位对虚拟内存进行映射时，如果物理内存不足，被换入换出到磁盘的是整个程序，这样势必会导致大量的磁盘读写操作，严重影响运行速度，所以这种方法还是显得粗糙，粒度比较大。

现代计算机都使用分页（Paging）的方式对虚拟地址空间和物理地址空间进行分割和映射，以减小换入换出的粒度，提高程序运行效率。

分页（Paging）的思想是指把地址空间人为地分成大小相等（并且固定）的若干份，这样的一份称为一页，就像一本书由很多页面组成，每个页面的大小相等。如此，就能够以页为单位对内存进行换入换出：

• 当程序运行时，只需要将必要的数据从磁盘读取到内存，暂时用不到的数据先留在磁盘中，什么时候用到什么时候读取。
• 当物理内存不足时，只需要将原来程序的部分数据写入磁盘，腾出足够的空间即可，不用把整个程序都写入磁盘。

关于页的大小

页的大小是固定的，由硬件决定，或硬件支持多种大小的页，由操作系统选择决定页的大小。比如 Intel Pentium 系列处理器支持 4KB 或 4MB 的页大小，那么操作系统可以选择每页大小为 4KB，也可以选择每页大小为 4MB，但是在同一时刻只能选择一种大小，所以对整个系统来说，也就是固定大小的。

目前几乎所有PC上的操作系统都是用 4KB 大小的页。假设我们使用的PC机是32位的，那么虚拟地址空间总共有 4GB，按照 4KB 每页分的话，总共有 2^32 / 2^12 = 2^20 = 1M = 1048576 个页；物理内存也是同样的分法。

根据页进行映射

下面我们通过一个简单的例子来说明虚拟地址是如何根据页来映射到物理地址的，请先看下图：

程序1和程序2的虚拟空间都有8个页，为了方便说明问题，我们假设每页大小为 1KB，那么虚拟地址空间就是 8KB。假设计算机有13条地址线，即拥有 2^13 的物理寻址能力，那么理论上物理空间可以多达 8KB。但是出于种种原因，购买内存的资金不够，只买得起 6KB 的内存，所以物理空间真正有效的只是前 6KB。

当我们把程序的虚拟空间按页分隔后，把常用的数据和代码页加载到内存中，把不常用的暂时留在磁盘中，当需要用到的时候再从磁盘中读取。上图中，我们假设有两个程序 Program 1 和 Program 2，它们的部分虚拟页面被映射到物理页面，比如 Program 1 的 VP0、VP1 和 VP7 分别被映射到 PP0、PP2 和 PP3；而有部分却留在磁盘中，比如 VP2、VP3 分别位于磁盘的 DP0、DP1中；另外还有一些页面如 VP4、VP5、VP6 可能尚未被用到或者访问到，它们暂时处于未使用状态。

这里，我们把虚拟空间的页叫做虚拟页（VP，Virtual Page），把物理内存中的页叫做物理页（PP，Physical Page），把磁盘中的页叫做磁盘页（DP，Disk Page）。

图中的线表示映射关系，可以看到，Program 1 和 Program 2 中的有些虚拟页被映射到同一个物理页，这样可以实现内存共享。

Program 1 的 VP2、VP3 不在内存中，但是当进程需要用到这两个页的时候，硬件会捕获到这个消息，就是所谓的页错误（Page Fault），然后操作系统接管进程，负责将 VP2 和 PV3 从磁盘中读取出来并且装入内存，然后将内存中的这两个页与 VP2、VP3 之间建立映射关系。

分页机制的实现

直接使用数组转换

最容易想到的映射方案是使用数组：每个数组元素保存一个物理地址，而把虚拟地址作为数组下标，这样就能够很容易地完成映射，并且效率不低。如下图所示：

但是这样的数组有 2^32 个元素，每个元素大小为4个字节，总共占用16GB的内存，显现是不现实的！

使用一级页表

既然内存是分页的，只要我们能够定位到数据所在的页，以及它在页内的偏移（也就是距离页开头的字节数），就能够转换为物理地址。例如，一个 int 类型的值保存在第 12 页，页内偏移为 240，那么对应的物理地址就是 2^12 * 12 + 240 = 49392。

2^12 为一个页的大小，也就是4K。

虚拟地址空间大小为 4GB，总共包含 2^32 / 2^12 = 2^20 = 1K * 1K  = 1M = 1048576 个页面，我们可以定义一个这样的数组：它包含 2^20 = 1M 个元素，每个元素的值为页面编号（也就是位于第几个页面），长度为4字节，整个数组共占用4MB的内存空间。这样的数组就称为页表（Page Table），它记录了地址空间中所有页的编号。

虚拟地址长度为32位，我们不妨进行一下切割，将高20位作为页表数组的下标，低12位作为页内偏移。如下图所示：

页表数组共有 2^20 = 1M 个元素，使用虚拟地址的高20位作为下标，正好能够访问数组中的所有元素；并且，一个页面的大小为 2^12 = 4KB，使用虚拟地址的低12位恰好能够表示所有偏移。

注意，表示页面编号只需要 20 位，而页表数组的每个元素的长度却为 4 字节，即 32 位，多出 32 - 20 = 12 位。这 12 位也有很大的用处，可以用来表示当前页的相关属性，例如是否有读写权限、是否已经分配物理内存、是否被换出到硬盘等。

例如一个虚拟地址 0XA010BA01，它的高20位是 0XA010B，所以需要访问页表数组的第 0XA010B 个元素，才能找到数据所在的物理页面。假设页表数组第 0XA010B 个元素的值为 0X0F70AAA0，它的高20位为 0X0F70A，那么就可以确定数据位于第 0X0F70A 个物理页面。再来看虚拟地址，它的低12位是 0XA01，所以页内偏移也是 0XA01。有了页面索引和页内偏移，就可以算出物理地址了。经过计算，最终的物理地址为 0X0F70A * 2^12 + 0XA01 = 0X0F70A000 + 0XA01 = 0X0F70AA01。

这种思路所形成的映射关系如下图所示：

可以发现，有的页被映射到物理内存，有的被映射到硬盘，不同的映射方式可以由页表数组元素的低12位来控制。

使用这种方案，不管程序占用多大的内存，都要为页表数组分配4M的内存空间（页表数组也必须放在物理内存中），因为虚拟地址空间中的高1G或2G是被系统占用的，必须保证较大的数组下标有效。

现在硬件很便宜了，内存容量大了，很多电脑都配备4G或8G的内存，页表数组占用4M内存或许不觉得多，但在32位系统刚刚发布的时候，内存还是很紧缺的资源，很多电脑才配备100M甚至几十兆的内存，4M内存就显得有点大了，所以还得对上面的方案进行改进，压缩页表数组所占用的内存。

使用两级页表

上面的页表共有 2^20 = 2^10 _ 2^10 个元素，为了压缩页表的存储空间，可以将上面的页表分拆成 2^10 = 1K = 1024 个小的页表，这样每个页表只包含 2^10 = 1K = 1024 个元素，占用 2^10 _ 4 = 4KB 的内存，也即一个页面的大小。这 1024 个小的页表，可以存储在不同的物理页，它们之间可以是不连续的。

那么问题来了，既然这些小的页表分散存储，位于不同的物理页，该如何定位它们呢？也就是如何记录它们的编号（也即在物理内存中位于第几个页面）。

1024 个页表有 1024 个索引，所以不能用一个指针指向它们，必须将这些索引再保存到一个额外的数组中。这个额外的数组有1024个元素，每个元素记录一个页表所在物理页的编号，长度为4个字节，总共占用4KB的内存。我们将这个额外的数组称为页目录（Page Directory），因为它的每一个元素对应一个页表。

如此，只要使用一个指针来记住页目录的地址即可，等到进行地址转换时，可以根据这个指针找到页目录，再根据页目录找到页表，最后找到物理地址，前后共经过3次间接转换。

那么，如何根据虚拟地址找到页目录和页表中相应的元素呢？我们不妨将虚拟地址分割为三分部，高10位作为页目录中元素的下标，中间10位作为页表中元素的下标，最后12位作为页内偏移，如下图所示：

前面我们说过，知道了物理页的索引和页内偏移就可以转换为物理地址了，在这种方案中，页内偏移可以从虚拟地址的低12位得到，但是物理页索引却保存在 1024 个分散的小页表中，所以就必须先根据页目录找到对应的页表，再根据页表找到物理页索引。

例如一个虚拟地址 0011000101  1010001100  111100001010，它的高10位为 0011000101，对应页目录中的第 0011000101 个元素，假设该元素的高20位为 0XF012A，也即对应的页表在物理内存中的编号为 0XF012A，这样就找到了页表。虚拟地址中间10位为 1010001100，它对应页表中的第 1010001100 个元素，假设该元素的高20位为 0X00D20，也即物理页的索引为 0X00D20。通过计算，最终的物理地址为 0X00D20 * 2^12 + 111100001010 = 0X00D20F0A。

这种思路所形成的映射关系如下图所示：

图中的点状虚线说明了最终的映射关系。图中没有考虑映射到硬盘的情况。

采用这样的两级页表的一个明显优点是，如果程序占用的内存较少，分散的小页表的个数就会远远少于1024个，只会占用很少的一部分存储空间（远远小于4M）。

在极少数的情况下，程序占用的内存非常大，布满了4G的虚拟地址空间，这样小页表的数量可能接近甚至等于1024，再加上页目录占用的存储空间，总共是 4MB+4KB，比上面使用一级页表的方案仅仅多出4KB的内存。这是可以容忍的，因为很少出现如此极端的情况。

也就是说，使用两级页表后，页表占用的内存空间不固定，它和程序本身占用的内存空间成正比，从整体上来看，会比使用一级页表占用的内存少得多。

使用多级页表

对于64位环境，虚拟地址空间达到 256TB，使用二级页表占用的存储空间依然不小，所以会更加细化，从而使用三级页表甚至多级页表，这样就会有多个页目录，虚拟地址也会被分割成多个部分，思路和上面是一样的，不再赘述。

内存管理单元MMU

通过页表完成虚拟地址和物理地址的映射时，要经过多次转换，还要进行计算，如果由操作系统来完成这项工作，那将会成倍降低程序的性能，得不偿失，所以这种方式是不现实的。

在CPU内部，有一个部件叫做MMU（Memory Management Unit，内存管理单元），由它来负责将虚拟地址映射为物理地址，如下图所示：

在页映射模式下，CPU 发出的是虚拟地址，也就是我们在程序中看到的地址，这个地址会先交给 MMU，经过 MMU 转换以后才能变成了物理地址。

即便是这样，MMU也要访问好几次内存，性能依然堪忧，所以在MMU内部又增加了一个缓存，专门用来存储页目录和页表。MMU内部的缓存有限，当页表过大时，也只能将部分常用页表加载到缓存，但这已经足够了，因为经过算法的巧妙设计，可以将缓存的命中率提高到 90%，剩下的10%的情况无法命中，再去物理内存中加载页表。

有了硬件的直接支持，使用虚拟地址和使用物理地址相比，损失的性能已经很小，在可接受的范围内。

MMU 只是通过页表来完成虚拟地址到物理地址的映射，但不会构建页表，构建页表是操作系统的任务。在程序加载到内存以及程序运行过程中，操作系统会不断更新程序对应的页表，并将页目录的物理地址保存到 CR3 寄存器。MMU 向缓存中加载页表时，会根据 CR3 寄存器找到页目录，再找到页表，最终通过软件和硬件的结合来完成内存映射。

CR3 是CPU内部的一个寄存器，专门用来保存页目录的物理地址。

每个程序在运行时都有自己的一套页表，切换程序时，只要改变 CR3 寄存器的值就能够切换到对应的页表。

对内存权限的控制

MMU 除了能够完成虚拟地址到物理地址的映射，还能够对内存权限进行控制。在页表数组中，每个元素占用4个字节，也即32位，我们使用高20位来表示物理页编号，还剩下低12位，这12位就用来对内存进行控制，例如，是映射到物理内存还是映射到磁盘，程序有没有访问权限，当前页面有没有执行权限等。

操作系统在构建页表时将内存权限定义好，当MMU对虚拟地址进行映射时，首先检查低12位，看当前程序是否有权限使用，如果有，就完成映射，如果没有，就产生一个异常，并交给操作系统处理。操作系统在处理这种内存错误时一般比较粗暴，会直接终止程序的执行。

C语言程序的内存结构（内存模型）

程序内存在地址空间中的分布情况称为内存模型（Memory Model）。

内核空间和用户空间

对于32位环境，理论上程序可以拥有 4GB 的虚拟地址空间，我们在C语言中使用到的变量、函数、字符串等都会对应内存中的一块区域。

在这4GB的地址空间中，要拿出一部分给操作系统内核使用，应用程序无法直接访问这一段内存，这一部分内存地址被称为内核空间（Kernel Space）。

Windows 在默认情况下会将高地址的 2GB 空间分配给内核（也可以配置为1GB），而 Linux 默认情况下会将高地址的 1GB 空间分配给内核。也就是说，应用程序只能使用剩下的 2GB 或 3GB 的地址空间，称为用户空间（User Space）。

Linux下32位环境的用户空间内存分布情况

我们暂时不关心内核空间的内存分布情况，下图是Linux下32位环境的一种经典内存模型：

对各个内存分区的说明：

|
内存分区 |
说明 |

| — | — |
|
程序代码区

            (code) | 
            存放函数体的二进制代码。一个C语言程序由多个函数构成，C语言程序的执行就是函数之间的相互调用。 |

|
常量区

            (constant) | 
            存放一般的常量、字符串常量等。这块内存只有读取权限，没有写入权限，因此它们的值在程序运行期间不能改变。 |

|
全局数据区

            (global data) | 
            存放全局变量、静态变量等。这块内存有读写权限，因此它们的值在程序运行期间可以任意改变。 |

|
堆区

            (heap) | 
            一般由程序员分配和释放，若程序员不释放，程序运行结束时由操作系统回收。[malloc()](/cpp/html/137.html)、[calloc()](/cpp/html/134.html)、[free()](/cpp/html/135.html) 等函数操作的就是这块内存，这也是本章要讲解的重点。

            

            注意：这里所说的堆区与数据结构中的堆不是一个概念，堆区的分配方式倒是类似于链表。 |

|
动态链接库 |
用于在程序运行期间加载和卸载动态链接库。 |
|
栈区

            (stack) | 
            存放函数的参数值、局部变量的值等，其操作方式类似于数据结构中的栈。 |

Linux下64位环境的用户空间内存分布情况

在64位环境下，虚拟地址空间大小为 256TB，Linux 将高 128TB 的空间分配给内核使用，而将低 128TB 的空间分配给用户程序使用。如下图所示：

Windows 32位程序的内存分布：

关于 Windows 地址空间的内存分布，官网上只给出了简单的说明：

• 对于32位程序，内核占用较高的 2GB，剩下的 2GB 分配给用户程序；
• 对于64位程序，内核占用最高的 248TB，用户程序占用最低的 8TB。

下图是一个典型的 Windows 32位程序的内存分布：

Windows 64位程序的地址空间分布情况如下图所示：

函数与栈

涉及汇编知识，不懂绕过。

栈帧/活动记录

当发生函数调用时，会将函数运行需要的信息全部压入栈中，这常常被称为栈帧（Stack Frame）或活动记录（Activate Record）。

活动记录一般包括以下几个方面的内容：

1. 函数的返回地址，也就是函数执行完成后从哪里开始继续执行后面的代码。例如：

int a, b, c;
func(1, 2);
c = a + b;

站在C语言的角度看，func() 函数执行完成后，会继续执行c=a+b;语句，那么返回地址就是该语句在内存中的位置。

注意：C语言代码最终会被编译为机器指令，确切地说，返回地址应该是下一条指令的地址，这里之所以说是下一条C语言语句的地址，仅仅是为了更加直观地说明问题。

2.
参数和局部变量。有些编译器，或者编译器在开启优化选项的情况下，会通过寄存器来传递参数，而不是将参数压入栈中，我们暂时不考虑这种情况。

3.
编译器自动生成的临时数据。例如，当函数返回值的长度较大（比如占用40个字节）时，会先将返回值压入栈中，然后再交给函数调用者。

当返回值的长度较小（char、int、long 等）时，不会被压入栈中，而是先将返回值放入寄存器，再传递给函数调用者。

4. 一些需要保存的寄存器，例如 ebp、ebx、esi、edi 等。之所以要保存寄存器的值，是为了在函数退出时能够恢复到函数调用之前的场景，继续执行上层函数。

下图是一个函数调用的实例：

上图是在Windows下使用VS2010 Debug模式编译时一个函数所使用的栈内存，可以发现，理论上 ebp 寄存器应该指向栈底，但在实际应用中，它却指向了old ebp。

在寄存器名字前面添加“old”，表示函数调用之前该寄存器的值。

当发生函数调用时：

• 实参、返回地址、ebp 寄存器首先入栈；
• 然后再分配一块内存供局部变量、返回值等使用，这块内存一般比较大，足以容纳所有数据，并且会有冗余；
• 最后将其他寄存器的值压入栈中。

需要注意的是，不同编译器在不同编译模式下所产生的函数栈并不完全相同，例如在VS2010下选择Release模式，编译器会进行大量优化，函数栈的样貌荡然无存，不具有教学意义，所以本教程以VS2010 Debug模式为例进行分析。

关于数据的定位

由于 esp 的值会随着数据的入栈而不断变化，要想根据 esp 找到参数、局部变量等数据是比较困难的，所以在实现上是根据 ebp 来定位栈内数据的。ebp 的值是固定的，数据相对 ebp 的偏移也是固定的，ebp 的值加上偏移量就是数据的地址。

例如一个函数的定义如下：

void func(int a, int b){
    float f = 28.5;
    int n = 100;
    //TODO:
}

调用形式为：

func(15, 92);

那么函数的活动记录如下图所示：

这里我们假设两个局部变量挨着，并且第一个变量和 old ebp 也挨着（实际上它们之间有4个字节的空白），如此，第一个参数的地址是 ebp+12，第二个参数的地址是 ebp+8，第一个局部变量的地址是 ebp-4，第二个局部变量的地址是 ebp-8。

函数调用惯例(Calling Convention)

函数调用惯例在函数声明和函数定义时都可以指定，语法格式为：

返回值类型  调用惯例  函数名(函数参数)

在函数声明处是为调用方指定调用惯例，而在函数定义处是为被调用方（也就是函数本身）指定调用惯例。

**cdecl是C语言默认的调用惯例，在平时编程中，我们其实很少去指定调用惯例，这个时候就使用默认的 **cdecl。

注意：**cdecl 并不是标准关键字，上面的写法在 VC/VS 下有效，但是在 GCC 下，要使用 **attribute__((cdecl))。

除了 cdecl，还有其他调用惯例，请看下表：

|
调用惯例 |
参数传递方式 |
参数出栈方式 |
名字修饰 |

| — | — | — | — |
|
cdecl |
按照从右到左的顺序入栈 |
调用方 |
下划线+函数名，

            如函数 max() 的修饰名为 _max |

|
stdcall |
按照从右到左的顺序入栈 |
函数本身

            （被调用方） | 
            下划线+函数名+@+参数的字节数，

            如函数 int max(int m, int n) 的修饰名为 _max_@8 |

|
fastcall |
将部分参数放入寄存器，

            剩下的参数按照从右到左的顺序入栈 | 
            函数本身

            （被调用方） | 
            @+函数名+@+参数的字节数 |

|
pascal |
按照从左到右的顺序入栈 |
函数本身

            （被调用方） | 
            较为复杂，这里不再展开讨论

              |

内存泄漏

使用 malloc()、calloc()、realloc() 动态分配的内存，如果没有指针指向它，就无法进行任何操作，这段内存会一直被程序占用，直到程序运行结束由操作系统回收。

请看下面的代码：

#include <stdio.h>
#include <stdlib.h>
int main(){
    char *p = (char*)malloc(100 * sizeof(char));
    p = (char*)malloc(50 * sizeof(char));
    free(p);
    p = NULL;
    return 0;
}

该程序中，第一次分配 100 字节的内存，并将 p 指向它；第二次分配 50 字节的内存，依然使用 p 指向它。

这就导致了一个问题，第一次分配的 100 字节的内存没有指针指向它了，而且我们也不知道这块内存的地址，所以就再也无法找回了，也没法释放了，这块内存就成了垃圾内存，虽然毫无用处，但依然占用资源，唯一的办法就是等程序运行结束后由操作系统回收。

这就是内存泄露（Memory Leak），可以理解为程序和内存失去了联系，再也无法对它进行任何操作。