[PATCH 1/2] [0.4.8] eloop extension for dbus control interface, v2

[Dan Williams]

On Mon, 2006-04-17 at 06:22 -0700, Jouni Malinen wrote:
> On Mon, Apr 17, 2006 at 08:42:21AM -0400, Dan Williams wrote:
> > On Sun, 2006-04-16 at 19:26 -0700, Jouni Malinen wrote:
> > > This looks quite good. However, type casting a function pointer to
> > > different type and then calling read_sock handler function with one
> > > extra parameter looks somewhat scary.. Is that guaranteed to work with
> > > all commonly used ANSI C compilers and CPUs?
> > 
> > AFAIK it does, but I'd have to check.  The glib/gtk compatibility
> > guidelines say something about this but I'll ping some gcc folk and ask.
> 
> After some additional thought on this area, I came up with a more
> detailed concern on this.. Thinking about calling conventions, there is
> a limit between N and N+1 function arguments where the compiler has to
> start using stack instead of registers for passing some of the
> arguments.. Because of this, I would assume that this kind of additional
> parameter cannot work in general case. In other words, there may be a
> need for adding a flag for the backwards compatibility case to know to
> use a different call (one less argument) for it.

Ok, the reason I was hoping to be able to pass in the signal type is so
that users wouldn't have to have 3 different dispatcher functions just
to process signals.  So the (messier) alternative here is to remove the
passing of the EloopEventType parameter into the callback, and require
eloop users to register a different function for each type of event
instead of being able to use the same one for everything and put a
switch() statement in it.

Sound OK?

Dan