50ea9c5b1c
Due to what is arguably a mistake in the C language specification, passing NULL to memcpy and friends is undefined behavior (UB) even when the count is 0. C additionally mistakenly leaves NULL + 0 and NULL - NULL undefined. (C++ fixes this mistake.) These are very problematic because (NULL, 0) is a natural representation of the empty slice. Some details: https://github.com/llvm/llvm-project/issues/49459 https://www.imperialviolet.org/2016/06/26/nonnull.html Unfortunately, despite how clearly this is a mistake, glibc headers and GCC now try to exploit this specification mistake and will miscompile code, so C projects need to workaround this. In particular, UBSan from Clang will flag this as a bug (although Clang itself has the good sense to never lean on this bug). We've run into a few UBSan errors in Chromium stemming from Wayland's memcpy calls. Add runtime guards as needed to avoid these cases. Note: Chromium's copy of wayland has https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188 applied. It is possible the ring_buffer_copy UB cases are only reachable with that MR applied, I'm not sure. But it seemed simplest to just add the fix to wayland as-is. Then when/if that MR lands, it will pick this up. Signed-off-by: David Benjamin <davidben@google.com> |
||
|---|---|---|
| .gitlab/issue_templates | ||
| cursor | ||
| doc | ||
| egl | ||
| protocol | ||
| src | ||
| tests | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .triage-policies.yml | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| meson.build | ||
| meson_options.txt | ||
| README.md | ||
| release.sh | ||
| releasing.txt | ||
| wayland-scanner.m4 | ||
| wayland-scanner.mk | ||
Wayland
Wayland is a project to define a protocol for a compositor to talk to its clients as well as a library implementation of the protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.
The wayland protocol is essentially only about input handling and buffer management. The compositor receives input events and forwards them to the relevant client. The clients creates buffers and renders into them and notifies the compositor when it needs to redraw. The protocol also handles drag and drop, selections, window management and other interactions that must go through the compositor. However, the protocol does not handle rendering, which is one of the features that makes wayland so simple. All clients are expected to handle rendering themselves, typically through cairo or OpenGL.
Building the wayland libraries is fairly simple, aside from libffi, they don't have many dependencies:
$ git clone https://gitlab.freedesktop.org/wayland/wayland
$ cd wayland
$ meson build/ --prefix=PREFIX
$ ninja -C build/ install
where PREFIX is where you want to install the libraries.
See https://wayland.freedesktop.org for documentation.