The check here guards the read below.
For `XimType_XIMStyles`, these are `num` of `CARD32` and for
`XimType_XIMHotKeyTriggers` these are `num` of `XIMTRIGGERKEY` ref[1]
which is defined as 3 x `CARD32`. (There are data after the
`XIMTRIGGERKEY` according to the spec but they are not read by this
function and doesn't need to be checked.)
The old code here used the native datatype size instead of the wire
protocol size causing the check to always fail.
Also fix the size calculation for the header (size). It is 2 x CARD16
for both types despite the unused `CARD16` for `XimType_XIMStyles`.
This fixes a regression caused by previous commit.
On mips64, the compiler does not allow use of non-zero argument with
__builtin_frame_address(). However, the returned frame address is only
used when PIPE_ARCH_X86 is defined. The compile error can be avoided
by making #ifdef PIPE_ARCH_X86 cover the getting of frame address too.
The argument checking of __builtin_frame_address() has been present
as a debug assert in clang 8. In clang 10, there is a proper runtime
check for the argument. This is why the build has not failed before.
OK jsg@
The VIDIOC_REQBUFS ioctl requires a v4l2_requestbuffers struct with the members
count, type, and memory. In the past only count was set as the uvideo(4) kernel
driver, via uvideo_reqbufs(), is ignoring both struct members type and memory
(pointed out by mpi@).
However, using video(1) with libv4l
(LD_PRELOAD=/usr/local/lib/v4l2convert.so video)
yields "mmap: Invalid argument" as libv4l inspects the type and memory
struct members and fails if memory != V4L2_MEMORY_MMAP.
Full initialization fixes libv4l usage which allows us to view video encodings
not directly supported by video(1), e.g., MJPEG, as libv4l can convert
encodings on the fly.
OK mglocker@
24bpp support is going away, so since we can't do 32bpp and these cards
have basically no VRAM to begin with, drop to 16bpp.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
quoted arguments are stored for other window managers.
The quotation handling happens within the while loop without checking if
the "end" limit has been already reached. If this happens, the final
NULL assignment leads to an out of boundary write on stack.
OK okan@
