Commits on Source (6)
-
Pekka Paalanen authoredThat build option has been long gone. cairo-image is the only flavor used nowadays. Signed-off-by:Pekka Paalanen <pekka.paalanen@collabora.com>
27cf5046 -
Pekka Paalanen authored
Drop the even more home-grown alloc wrapper and use the xalloc.h wrappers directly. xcalloc() is added and used, because calloc() will detect integer overflows in the size multiplication, while doing a simple multiplication in the caller is subject to overflows which may result in allocating not what was expected, subjecting to out-of-bounds access. All MEM_ALLOC() calls that had a meaningful multiplication in them were converted to xcalloc(), the rest to xzalloc(). Signed-off-by:cbbf0e59 -
Pekka Paalanen authored
Recently I learnt that fprintf() is not async-signal-safe. Maybe it also attempts to allocate memory sometimes. Hence, using it when we presumably are out of memory is wishful thinking. Therefore replace that with async-signal-safe code. If you have to check pointers from traditional signal handlers, now you could do that too! While doing this, we also lose the string formatting for line number. I would argue that printing file and line number is not that useful, if the system really is out of memory. If not out of memory, a core dump would give us much more detailed information about what went wrong. clients/window.c had some calls to fail_on_null() and these are simply replaced. They were used for checking that creating new wl_proxy by issuing a protocol request worked, and IIRC that only fails on out-of-memory, so the same rationale applies here. Signed-off-by:9229a451 -
Pekka Paalanen authored
This file relied on shared/xalloc.h to include <libweston/zalloc.h>. That would be a problem if xalloc.h stopped doing that. Just use xzalloc(). Signed-off-by:c95feefb -
Pekka Paalanen authored
The definition of zalloc is trivial, so let's just have it here instead of loading libweston/zalloc.h. Now xalloc.h does not depend on any libweston header, which makes me feel slightly better. It's more clean. Who knows, maybe one day libweston/zalloc.h will be removed. Signed-off-by:fc26c749 -
Pekka Paalanen authored
There are many reasons why trying to handle malloc() returning NULL by any other way than calling abort() is not beneficial: - Usually malloc() does not return NULL, thanks to memory overcommit. Instead, the program gets SIGSEGV signal when it tries to access the memory. - Trying to handle NULL will create failure paths that are impractical to test. There is no way to be sure the compositor still works once such path is actually taken. - Those failure path will clutter the code, increasing maintenance and development burden. - Sometimes there just isn't a good way to handle the failure. For more discussion, see the issue link below. Closes: wayland/weston#631 Signed-off-by:
93587067