The bigreq request-length test ignored the return value of the write()
that sends the hand-built request, which gcc flags as -Werror=unused-result
(seen on the gentoo lane once -Dwerror is enabled). Treat a short/failed
write as the "something else went wrong" case (return 2) — the test can't
have exercised the bug if the request never went out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The failing struct comes from the python test written by Michal Srb
<msrb@suse.com>.
v2: Use a drawable (root window) and gc, so that PolyLines hopefully
actually tries processing things. However, the request seems to
process successfully so the poll() just stalls out. However, this
does let us distinguish between detecting the bigrequests error
and not, at least.
v3: Clean up the description of what we expect the poll() call to do.
v4: Use XI2 instead of PolyLine to trigger a predictable error. We know the
server replies with BadValue for a zero num_masks argument. So if we send
a bigreq with a num_masks 0 and a length 0, we can just check whether we
get killed (good) or a BadValue (bad). It doesn't test for specific memory
overflows or crashes, but based on the assumption that we shouldn't look
at *any* BigReq of size 0, this seems to be sufficient.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
