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