Currently, it is cumbersome for clients that want to know what version of an
interface is supported at compile time. This can especially matter in cases
where the compositor and client aren't neccesarily compiled against the same
wayland and wayland protocol versions. Provide more information by adding a
simple int define for all interfaces that give the version that is already
defined in the source xml file.
Signed-off-by: Dudemanguy <random342@airmail.cc>
If a wl_array has size zero, wl_array_for_each computes NULL + 0 to get
to the end pointer. This should be fine, and indeed it would be fine in
C++. But the C specification has a mistake here and it is actually
undefined behavior. See
https://davidben.net/2024/01/15/empty-slices.html
Clang's -fsanitize=undefined flags this. I ran into this in Chromium's
build with wayland-scanner on one of our XML files.
../../third_party/wayland/src/src/scanner.c:1853:2: runtime error: applying zero offset to null pointer
#0 0x55c979b8e02c in emit_code third_party/wayland/src/src/scanner.c:1853:2
#1 0x55c979b89323 in main third_party/wayland/src/src/scanner.c
#2 0x7f8dfdb8c6c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#3 0x7f8dfdb8c784 in __libc_start_main csu/../csu/libc-start.c:360:3
#4 0x55c979b70f39 in _start (...)
An empty XML file is sufficient to hit this case, so I've added it as a
test. To reproduce, undo the fix and include only the test, then build
with:
CC=clang CFLAGS="-fno-sanitize-recover=undefined" meson build/ -Db_sanitize=undefined -Db_lundef=false
ninja -C build test
Signed-off-by: David Benjamin <davidben@google.com>
