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>
The test runs wayland_scanner on a set of XML protocol files which
have malformed element names, and confirms that an error is produced
and indicates the correct line.
Copyright notifications are not included in the test files, as
they are not code; of course, the project license still applies.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
First one is deprecated in favour of the second option.
The latter is newly introduced and annotates the generated symbols
accordingly.
v2: Don't introduce small-public-code.c - reuse small-code.c (Pekka)
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Add tests that ensure that wayland-scanner output for a given input does
not change unexpectedly. This makes it very easy to review
wayland-scanner patches.
Before, when patches were proposed for wayland-scanner, I had to
build wayland without the patches, save the generated files into a
temporary directory, apply the patches, build again, and diff the old
vs. new generated file.
No more. Now whenever someone makes intentional changes to
wayland-scanner's output, he will also have to patch the example output
files to match. That means that reviewers see the diff of the generated
files straight from the patch itself. Verifying the diff is true is as
easy as 'make check'.
The tests use separate example XML files instead of wayland.xml
directly, so that wayland.xml can be updated without fixing scanner
tests, avoiding the churn.
example.xml starts as a copy of wayland.xml. If wayland.xml starts using
new wayland-scanner features, they should be copied into example.xml
again to be covered by the tests.
This patch relies on the previous patch to actually add all the data
files for input and reference output.
The scanner output is fed through sed to remove parts that are allowed
to vary: the scanner version string.
v2: no need for scanner-test.sh to depend on the test data
Task: https://phabricator.freedesktop.org/T3313
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk> (v1)
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Tested-by: Yong Bakos <ybakos@humanoriented.com>
