fair enough. for my part i don't like writing code that does nothing (and i know nothing about windows or macintosh computers), but what you're proposing sounds reasonable and not very intrusive.
there are already wrappers in darktable.h: void *dt_alloc_align(size_t alignment, size_t size); void dt_free_align(void *mem); which may need to be amended a bit and probably they aren't used very consistently throughout the code base. occasionally there may also be some glib malloc wrapper in use.. cheers, jo On Tue, Jan 29, 2019 at 3:12 AM Mark Feit <mf...@notonthe.net> wrote: > > 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 > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
