mainnika
/
weston
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
8196 Commits
1 Branch
0 Tags
14 MiB
Tag: Branch: Tree: 9229a45116
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '9229a45116'
${ noResults }
weston/shared/xalloc.h

67 lines
2.0 KiB
Raw Normal View History Unescape

clients & tests: Unify multiple definitions of x*alloc and related functions Direct fail_on_null calls now produce output like: [weston-info] clients/weston-info.c:714: out of memory xmalloc, et al produce output on failure like: [weston-info] out of memory (-1) Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
9 years ago
/*
* Copyright © 2008 Kristian Høgsberg
shared: rewrite fail_on_null() as abort_oom_if_null() 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: Pekka Paalanen <pekka.paalanen@collabora.com>
2 years ago
* Copyright 2022 Collabora, Ltd.
clients & tests: Unify multiple definitions of x*alloc and related functions Direct fail_on_null calls now produce output like: [weston-info] clients/weston-info.c:714: out of memory xmalloc, et al produce output on failure like: [weston-info] out of memory (-1) Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
9 years ago
*
* Permission is hereby granted, free of charge, to any person obtaining
* a copy of this software and associated documentation files (the
* "Software"), to deal in the Software without restriction, including
* without limitation the rights to use, copy, modify, merge, publish,
* distribute, sublicense, and/or sell copies of the Software, and to
* permit persons to whom the Software is furnished to do so, subject to
* the following conditions:
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial
* portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
#ifndef WESTON_XALLOC_H
#define WESTON_XALLOC_H
#ifdef __cplusplus
extern "C" {
#endif
shared: Make xalloc.h stand alone Make fail_on_null static inline and put it in xalloc.h so we can use the header exclusively instead of having to link with the library for it. This is so we can use xalloc in places (like the RDP backend) without having to bring in libshared. Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
2 years ago
#include <errno.h>
clients & tests: Unify multiple definitions of x*alloc and related functions Direct fail_on_null calls now produce output like: [weston-info] clients/weston-info.c:714: out of memory xmalloc, et al produce output on failure like: [weston-info] out of memory (-1) Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
9 years ago
#include <stdlib.h>
shared: rewrite fail_on_null() as abort_oom_if_null() 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: Pekka Paalanen <pekka.paalanen@collabora.com>
2 years ago
#include <unistd.h>
clients & tests: Unify multiple definitions of x*alloc and related functions Direct fail_on_null calls now produce output like: [weston-info] clients/weston-info.c:714: out of memory xmalloc, et al produce output on failure like: [weston-info] out of memory (-1) Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
9 years ago
#include <string.h>
Rename zalloc.h to libweston/zalloc.h It is a public installed header used by libweston.h. See "Rename compositor.h to libweston/libweston.h" for rationale. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
6 years ago
#include <libweston/zalloc.h>
clients & tests: Unify multiple definitions of x*alloc and related functions Direct fail_on_null calls now produce output like: [weston-info] clients/weston-info.c:714: out of memory xmalloc, et al produce output on failure like: [weston-info] out of memory (-1) Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
9 years ago
shared: Make xalloc.h stand alone Make fail_on_null static inline and put it in xalloc.h so we can use the header exclusively instead of having to link with the library for it. This is so we can use xalloc in places (like the RDP backend) without having to bring in libshared. Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
2 years ago
static inline void *
shared: rewrite fail_on_null() as abort_oom_if_null() 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: Pekka Paalanen <pekka.paalanen@collabora.com>
2 years ago
abort_oom_if_null(void *p)
shared: Make xalloc.h stand alone Make fail_on_null static inline and put it in xalloc.h so we can use the header exclusively instead of having to link with the library for it. This is so we can use xalloc in places (like the RDP backend) without having to bring in libshared. Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
2 years ago
{
shared: rewrite fail_on_null() as abort_oom_if_null() 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: Pekka Paalanen <pekka.paalanen@collabora.com>
2 years ago
static const char oommsg[] = ": out of memory\n";
if (p)
return p;
write(STDERR_FILENO, program_invocation_short_name,
strlen(program_invocation_short_name));
write(STDERR_FILENO, oommsg, strlen(oommsg));
shared: Make xalloc.h stand alone Make fail_on_null static inline and put it in xalloc.h so we can use the header exclusively instead of having to link with the library for it. This is so we can use xalloc in places (like the RDP backend) without having to bring in libshared. Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
2 years ago
shared: rewrite fail_on_null() as abort_oom_if_null() 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: Pekka Paalanen <pekka.paalanen@collabora.com>
2 years ago
abort();
shared: Make xalloc.h stand alone Make fail_on_null static inline and put it in xalloc.h so we can use the header exclusively instead of having to link with the library for it. This is so we can use xalloc in places (like the RDP backend) without having to bring in libshared. Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
2 years ago
}
clients & tests: Unify multiple definitions of x*alloc and related functions Direct fail_on_null calls now produce output like: [weston-info] clients/weston-info.c:714: out of memory xmalloc, et al produce output on failure like: [weston-info] out of memory (-1) Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
9 years ago
shared: rewrite fail_on_null() as abort_oom_if_null() 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: Pekka Paalanen <pekka.paalanen@collabora.com>
2 years ago
#define xmalloc(s) (abort_oom_if_null(malloc(s)))
#define xzalloc(s) (abort_oom_if_null(zalloc(s)))
#define xcalloc(n, s) (abort_oom_if_null(calloc(n, s)))
#define xstrdup(s) (abort_oom_if_null(strdup(s)))
#define xrealloc(p, s) (abort_oom_if_null(realloc(p, s)))
clients & tests: Unify multiple definitions of x*alloc and related functions Direct fail_on_null calls now produce output like: [weston-info] clients/weston-info.c:714: out of memory xmalloc, et al produce output on failure like: [weston-info] out of memory (-1) Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
9 years ago
#ifdef __cplusplus
}
#endif
#endif /* WESTON_XALLOC_H */