You don't know. It's true that the line of code he cited was incorrect. It's just not a very interesting example of incorrect code.
Malloc failures don't always result in aborting. The common alternative, especially in programs that have careful malloc return value checking regimes, is to occasionally cough up remote code execution.
Userland systems programmers should assume the conservative default of ending the program immediately when malloc fails.
A similar logic guided C++ into throwing bad_alloc instead of returning NULL on allocation failures. And a survey of modern C++ code will show you that most C++ programs simply allow themselves to terminate when bad_alloc happens.
It doesn't have to be interesting. Incorrect code covers a spectrum and is not black or white. The term "edge-case" describes it pretty well.
Regarding mallocs, again you don't have to overthink error-handling. Just handle it and figure out how to deal with it if it happens.
C++ has nothrow and try/catch. If you want to catch a failed new or abort is something up to the user. One thing for sure is that C++ aborts on failed new instead of stumping on unallocated memory.
On the other hand, consistency is important. Some parts of the code handled fd correctly and malloc failures and other parts did not.
I recommend you applaud good programming practices and criticize bad ones. Defending/arguing bad programming practices(whether they are edge cases or not) doesn't help.
Malloc failures don't always result in aborting. The common alternative, especially in programs that have careful malloc return value checking regimes, is to occasionally cough up remote code execution.
Userland systems programmers should assume the conservative default of ending the program immediately when malloc fails.
A similar logic guided C++ into throwing bad_alloc instead of returning NULL on allocation failures. And a survey of modern C++ code will show you that most C++ programs simply allow themselves to terminate when bad_alloc happens.