[FFmpeg-devel] [PATCH v5] avdevice/xcbgrab: check return values of xcb query functions

[Alexander Strasser]

Hi Andriy!

On 2020-07-19 19:47 -0400, Andriy Gelman wrote:
> On Sun, 19. Jul 23:19, Alexander Strasser wrote:
> > On 2020-07-16 23:54 -0400, Andriy Gelman wrote:
> > > On Tue, 14. Jul 14:14, Moritz Barsnick wrote:
[...]
> > > > --- a/libavdevice/xcbgrab.c
> > > > +++ b/libavdevice/xcbgrab.c
> > > > @@ -346,8 +346,10 @@ static void xcbgrab_draw_mouse(AVFormatContext *s, AVPacket *pkt,
> > > >          return;
> > > >
> > >
> > > >      cursor = xcb_xfixes_get_cursor_image_cursor_image(ci);
> > > > -    if (!cursor)
> > > > +    if (!cursor) {
> > > > +        free(ci);
> > > >          return;
> > > > +    }
> > >
> > > This check seems dead code. Looking at xcb sources, cursor is just an offset in
> > > memory from ci so I don't think it can be null here.
> >
> > It's great to look at the sources, but I don't think we should turn
> > an implementation snapshot into a guarantee.
> >
> > I guess it's safer to keep the check, if there is no documentation
> > about this being always non-NULL.
> >
> > I'm not entirely sure how well this is documented. Surely some of
> > functions definitely return NULL sometimes, which was the reason to
> > submit this patch, I would probably only assume non-NULL returns for
> > functions where that is explicitly documented.
>
> xcb_xfixes_get_cursor_image_cursor_image(ci) is just an accessor function to the
> reply:
>
> uint32_t *
> xcb_xfixes_get_cursor_image_cursor_image (const xcb_xfixes_get_cursor_image_reply_t *R)
> {
>     return (uint32_t *) (R + 1);
> }
>
> All the error handling should be done after the call to:
> ci = xcb_xfixes_get_cursor_image_reply(gr->conn, cc, NULL);
>
> We check whether ci == NULL, but you can also pass xcb_generic_error_t** and
> check the result.

My argument is, that ci could well have been allocated, but maybe
it doesn't contain cursor data and then

xcb_xfixes_get_cursor_image_cursor_image

checks for that and does return NULL instead of an offset. Or
xcb_xfixes_get_cursor_image_cursor_image is changed to allocate
an internally managed copy of the cursor at access time, which
could fail.

It's purely hypothetical, but it could happen. Being able to do
things differently at some point in the future is often part of
the argumentation for having accessor functions in the first
place, but it only works if the callers don't assume details
about the implementation.


> But anyway, this part of the patch doesn't really have anything to do with
> ticket #7312, and should be in a separate patch.

Yes, it's definitely something that was changed in this patch
at all. So it's better not to touch it in this patch.

If you really like to change it in the future, that is acceptable
for me though I don't really see the point. Maybe there is even
stronger guarantees around, that I fail to see documented in the
API docs I read so far.


  Alexander