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>

1 files changed, 6 insertions, 0 deletions

diff --git a/README.md b/README.md
index 81dbeae2..03e32392 100644
--- a/README.md
+++ b/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.