hostap_driver_data vs. driver_ops. A bug?
waynix at gmail.com
Sun Mar 27 02:30:03 EST 2005
Thanks Jouni. I got it.
This is kind of like hostap_driver_data being a "derived class" of driver_ops,
by virtual of the fact that the former has the latter as the first element.
That was a careless overlook on my part.
On Sat, 26 Mar 2005 18:00:12 -0800, Jouni Malinen <jkmaline at cc.hut.fi> wrote:
> On Sat, Mar 26, 2005 at 03:53:58PM -0800, wayne liu wrote:
> > hostap_driver_deinit() takes a parameter, void* priv, and casts it as
> > hostap_driver_data. But the caller of this routine, hostapd_driver_deinit(),
> > is passing in a param of type struct driver_ops when doing
> > hapd->driver->deinit(hapd->driver);
> The driver interface code (driver.c) uses struct hostap_driver_data as a
> data structure that starts with struct driver_ops, but has private
> variables in the end. Generic hostapd code does not know about these and
> only has a pointer to struct driver_ops. Anyway, these are pointing to
> the same address.
> > As a related issue, in hostap_init(), the locally malloc'ed
> > hostap_driver_data *drv does not seem to be held by anybody or free()'ed
> > at the end and hence is lost when call is returned.
> This pointer is stored in hapd->driver; this is due to drv and &drv->ops
> pointing to the same address.
> > So the question is should hapd->driver be pointing to hostap_driver_data
> > instead of driver_ops ?
> No, core hostapd code should not know anything about private driver
> interface structures (e.g., struct hostap_driver_data).
> > Given that the 1st variable of struct
> > hostap_driver_data
> > is driver_ops (by design?), access to any APIs in the driver_ops won't be
> > messed up by the mismatch of the param. But what about other data fields?
> Yes, this is by design; and no, this does not mess up other fields.
> Jouni Malinen PGP id EFC895FA
> HostAP mailing list
> HostAP at shmoo.com
More information about the HostAP