README: establish no-malloc-failures policy

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: https://gitlab.freedesktop.org/wayland/weston/-/issues/631

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

CONTRIBUTING.md

@@ -208,6 +208,10 @@ my_function(void)
                                              parameter3, parameter4);
 ```
 
+- do not write fallback paths for failed simple memory allocations, use the
+  `x*alloc()` wrappers from `shared/xalloc.h` instead or use
+  `abort_oom_if_null()`
+
 Conduct
 =======
 

README.md

@@ -18,6 +18,12 @@ bugs and shortcomings, we avoid unknown or variable behaviour as much as
 possible, including variable performance such as occasional spikes in frame
 display time.
 
+Weston and libweston are not suitable for memory constrained environments
+where the compositor is expected to continue running even in the face of
+trivial memory allocations failing. If standard functions like `malloc()`
+fail for small allocations,
+[you can expect libweston to abort](https://gitlab.freedesktop.org/wayland/weston/-/issues/631).
+
 A small suite of example or demo clients are also provided: though they can be
 useful in themselves, their main purpose is to be an example or test case for
 others building compositors or clients.