coding volunteers needed for msrpc server-side API conversion

[Elrond]

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