这个函数的可靠性如何？ 现在我有一个构建文件夹文件列表的任务，需要将某文件夹下面所有的文件纳入到一个序列之中，并进行排序。 我认为链表确实可以做到这个东西，但是我现在想要使用数组，但是由于事先不知道文件的数目，只能动态内存分配（用 malloc 分配连续的内存，再用 qsort 函数依据文件名做快速排序） 就是不知道 realloc 函数的可靠性怎么样？
可靠性指的是什么？
因为每加入一个文件就要 realloc 一次，我害怕导致内存分配失败。 （文件数目小于10万）
每个文件 realloc 一次不对啊。
那有什么更好一点的思路吗？因为事先真的不能确定文件的确切数目。（但是文件数目是小于10万）
那就直接malloc你最大需要的内存，反正是demanding page的，不会吃很多rss。
1 个赞
想到一种办法，就是先把他们放到链表里面去，同时为链表节点个数计数，最后统一申请一块内存，存储链表各个节点的地址。
realloc这个函数的设计非常的不好，通过man手册可以看出他做了很多函数名没有能够体现出来的事情。我的建议是不要用这个函数。使用不当时，还可能造成原有数据丢失，如常用的形式可能是x = realloc(x, newsize)，当内存不够导致失败时，x原本指向的数据就丢失了，存在风险。
1 个赞
你应该每次 realloc 分配当前 array 大小 2 倍或 1.5 倍的内存（Rust，C++ 标准库动态数组实现）
或者直接使用 uthash 提供的 utarray 动态数组实现 https://troydhanson.github.io/uthash/
1 个赞
按c的字符串，你这分配的应该就是些指针，10w个指针的内存大小也不算大。 如果不是在内存受限的机器上，在这个年代应该不会出现分配失败的吧？
8B * 100 000 = 不到 1MB，对 PC 来说真的不大
现在linux都开overcommit了，你随便malloc好了，即使malloc超过你物理内存的大小都会返回成功的，只要你最后没有access超过物理内存的page就行了，所以你真没必要用realloc，直接malloc一把梭就行。uva(userspace virtual memory area)是很廉价的。
1 个赞
这样写到你使用内存时系统拿不出 free pages 就可能会触发 OOM killer 。其次，32 位系统下只能用 2-4 GB 的 address space，不是很廉价，而且非 Linux 系统一般不会默认开启 overcommit。
另外，小 allocation 不一定会触发 overcommit。
1 个赞