On 1/28/19 3:15 AM, johannes hanika wrote:
re: malloc() and 0: linux overcommits, i.e. it will likely never
return 0 even if your memory is all full. this means checking for 0 is
completely useless in this context.
To be blunt, that reads like a rationalization for writing bad software.
Returning NULL when malloc() fails has been normal behavior since day
one; the standard that codified it celebrates its 30th anniversary this
year. Unless there's a compelling reason to do otherwise, code should
be written to the language standard, not the default behavior of the
operating system supervising it. The status quo does nothing to help
the ports for Windows, which doesn't overcommit, and OS X, which might
not (I can't find a solid reference one way or the other). And, of
course, it will break just the same on Linux systems that aren't set to
the default.
To continue Stefan's theme, a clean exit leaves a fighting chance that
dt's business will be successfully closed out; a SIGSEGV guarantees that
it won't. If wider use of dt is a goal of the project, making users
pick through configuration directories after a crash when it could have
been avoided won't help spur adoption.
I think wrappers for allocation has just become this week's project.
--Mark
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
