GTK+ is already using Xlib at a pretty low level - see gdk/x11/gdkasync.c. So just, say, copy what https://cgit.freedesktop.org/xorg/lib/libX11/tree/src/GetIFocus.c does and check the return value of _XReply() - if it's 0, then you got a BadAccess. (Or some other call if GetInputFocus doesn't do what you want.)
Going to XCB would be the clean solution, but I don't see introducing XCB usage into GTK+ as a good idea at this point - there are almost certainly subtle traps if mixing together XLib and XCB usage. Owen On Tue, Apr 20, 2021 at 7:30 AM Nekun <neko...@firemail.cc> wrote: > > Hi all. > > Can somebody explain me why BadAlloc and BadAccess errors are ignored in > Xlib reply processing, but only in certain conditions? As I can see > (maybe I misunderstood something, please correct), in _Xreply: > https://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xcb_io.c#n655 , > after sending a request, at first we process pending responses in input > buffer and handle it without any exceptions and then we process the last > response and ignore some errors: BadName and BadFont in some conditions > described in the Xlib spec: > https://www.x.org/releases/current/doc/libX11/libX11/libX11.html#Using_the_Default_Error_Handlers > , and, suddenly, completely ignore BadAccess and BadAlloc. I don't found > any references for that behavior. In result, I can't trap these errors > with my error handler if an Xlib request wrapper calls _Xreply > explicitly. Some wrappers, such as XBell, writes a request to output > queue, calls the sync handler and then errors are handled without > exception because XSync adds InputSetFocus to queue, so the target > request is processed with no-exception logic described above. This issue > arised when I worked on fixing the broken untrusted context check in GTK > (GDK) at display opening. I need a function which robustly returns an > error when we in untrusted context, which returned exactly when client > is untrusted and not for any other reasons, and throw in the gdk_x_error > trap. Tried XListHosts and failed for reasons described above. Maybe I > can use a return value of some function instead of error handling? Seems > like X11 security extension more often returns fake values for untrusted > clients rather than errors, but not sure that is possible to distinguish > between a fake value and a real in any response. Stucked here. > _______________________________________________ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel