coding volunteers needed for msrpc server-side API conversion
Elrond
Elrond at Wunder-Nett.org
Thu Jan 27 19:29:32 GMT 2000
On Fri, Jan 28, 2000 at 05:59:41AM +1100, Luke Kenneth Casson Leighton wrote:
> >
> > Do I see this right:
> >
> > xxx_io_q_xxx() is different from xxx_io_r_xxx(), when it
> > comes to dynamic memory?
>
> yes.
>
> > As I understood it:
> > xxx_io_q_xxx():
> > on the client-side:
> > just uses any memory --> no free()
> > on the server-side:
> > does malloc memory for received data --> malloc()
> > xxx_io_r_xxx():
> > on the client-side:
> > does malloc memory for received data --> malloc()
> > on the server-side:
> > does free the memory for send data --> free()
> >
> > I don't like this asymetry.
>
> well, the _real_ solution is to split client-side and server-side
> marhalling / unmarshalling.
>
> and i'm NOT doing that until we have some auto-generation mechanism, to
> keep the two sets of marshalling code in sync.
I like it, that the marshalling/unmarshalling is currently
in one function.
But I don't realy see the need for this asymmetry. The
using functions can clearly work around this:
In cli_*.c we do:
xxx_xxx(const foo in, foo **out)
xxx_make_q_xxx(in) /* this one dups all the neccessary things */
xxx_io_q_xxx() /* this one then frees them again */
...
xxx_io_r_xxx(&x) /* mallocs appropiate memory */
...
*out = x
That way, cli_*.c-functions only USE "in"-args, and malloc
"out"-args.
In srv_*.c we have:
dispatch_xxx_xxx()
xxx_io_r_xxx(&x) /* will mallocs memory for x */
...
_xxx_xxx(x, &y) /* will USE x, malloc y) */
...
free(x);
And in daemon/*_real.c
_xxx_xxx(const foo in, foo **out)
/* this function does real work */
/* will only USE in */
/* will malloc memory for out */
*out = malloc();
Okay... This should make
a) parsing symmetric.
b) let us "#define xxx_xxx _xxx_xxx", if we want.
> so, for now, we massage the code into something suitable, remove the
> marshalling / unmarshalling from actual _implementation_ of the functions,
> and _then_ we can go for auto-gen'd marshalling / unmarshalling.
>
> which is why it's important to use UNICODE strings not char*.
Hmmm... yes... (not yet completely convinced :-))
Elrond
More information about the samba-technical
mailing list