4 ms·

How do you know? What if someone forked this program and closed fd 0 before execX()? You have to abide by the posix standard and what the man page tells you. No

by halayli 12y ago

How do you know? What if someone forked this program and closed fd 0 before execX()? You have to abide by the posix standard and what the man page tells you. Now it never happens, but later the code can change and the case can hit. Most probably you'd have forgotten about this check. Malloc failures don't always have to result in aborting the program. Cases can vary. My suggestion to you is abide by the man page and always check error conditions. Don't overthink the failure cases of stdlib & posix calls. You never know the OS/environment your program will run in, and the only common ground you have is the standard.

tptacek 12y ago
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.
- halayli 12y ago
  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.
  - tptacek 12y ago
    I responded to this downthread.

by halayli 12y ago

tptacek 12y ago

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.

halayli 12y ago
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.
- tptacek 12y ago
  I responded to this downthread.