On 23 January 2017 at 19:32, Adam Jackson <a...@redhat.com> wrote: > The idea here is that the driver might have once been old enough to not > have the driverFunc slot in DriverRec, with the module ABI not having > changed when it was added. That was ages ago, and drivers always declare > themselves with DriverRec not DriverRec1, so uninitialized slots will > simply be zero. > > Signed-off-by: Adam Jackson <a...@redhat.com> > --- > hw/xfree86/common/xf86Helper.c | 9 +-------- > hw/xfree86/common/xf86str.h | 10 ---------- > 2 files changed, 1 insertion(+), 18 deletions(-) > > diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c > index f48af75..b464864 100644 > --- a/hw/xfree86/common/xf86Helper.c > +++ b/hw/xfree86/common/xf86Helper.c > @@ -79,14 +79,7 @@ xf86AddDriver(DriverPtr driver, void *module, int flags) > xf86DriverList = xnfreallocarray(xf86DriverList, > xf86NumDrivers, sizeof(DriverPtr)); Unrelated question: This is a rather common pattern - foo++; reallocarray(.. foo...) Wondering if starting with a base (say 8 ?) and doubling as the limit is reached isn't a more common/practical solution. Or there's (has been?) memory constrained environments where that was a bad idea ?
> xf86DriverList[xf86NumDrivers - 1] = xnfalloc(sizeof(DriverRec)); > - if (flags & HaveDriverFuncs) I was purging through this as well (as mentioned in the original series) and noticed that some drivers do not use/set the HaveDriverFuncs flag. Although looking at it now, we should be safe. Reviewed-by: Emil Velikov <emil.l.veli...@gmail.com> -Emil _______________________________________________ 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