Document the useles effort to handle small memory allocations. Even
the small test program below shows glibc's malloc wont return a NULL allocation. The
program will be killed by the OOM.
int main(int argc, char *argv[])
{
while (1) {
if (!malloc(16))
exit(3);
}
return 0;
}
$ ./malloc
[1] 25788 killed ./malloc
$ echo $?
137
[ 2729.844036] Out of memory: Killed process 25745 (malloc) total-vm:15131480kB,
anon-rss:14977108kB, file-rss:948kB, shmem-rss:0kB
[ 2730.091798] oom_reaper: reaped process 25745 (malloc), now anon-rss:0kB, file-rss:0kB,
shmem-rss:0kB
Linux userland system programming is different to embedded systems
where any sized malloc can and *will* fail.
---
doc/coding-style.txt | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/doc/coding-style.txt b/doc/coding-style.txt
index 97410ce72584..c2fdc717a14e 100644
--- a/doc/coding-style.txt
+++ b/doc/coding-style.txt
@@ -155,10 +155,19 @@ for (i = 0; i < 3; i++) {
}
-M8: Use g_try_malloc instead of g_malloc
-========================================
-When g_malloc fails, the whole program would exit. Most of time, this is not
-the expected behavior, and you may want to use g_try_malloc instead.
+M8: Abort if small allocation fail
+==================================
+When g_malloc fails, the whole program would exit. Small allocations
+are very unlikely to fail and if an allocations is not possible, it is
+very likely the error code can't recover from this
+situation. Furthermore, many of the error paths are not tested at
+all. Instead use g_malloc() when the allocation fails and rely on an
+external watchdog to restart the program.
+
+Furthermore, Glib's functions such as g_strdup use g_malloc which
+obviously terminates the program anyway.
+
+For large allocation using g_try_malloc is still the right choice.
Example:
additional = g_try_malloc(len - 1); // correct
--
2.24.0
Show replies by date