coding volunteers needed for msrpc server-side API conversion

[Luke Kenneth Casson Leighton]

> > yep!!!  you notice that if you cut out the marshalling  and unmarshalling
> > bits, the xxx_xxx() memory alliocation and usage and the _xxx_xxx() memory
> > allcation and usage are EXACTLY the same?
> 
> Yes, This was one of the goals, when I made this thing up.
> 
> > that's the way it _should_ be.
> 
> So, we do it _this_ way ?

yep.
 
> It's just, I would like to have some _nice_ rules, and have
> some. So I can start and rewrite things correctly.
> 
> I don't have problems, if some things don't follow the
> rules, but new (or rewritten) things should follow them.

i'm breaking them already by having something like this:

spoolss_r_xxx()
{
	....
	....
	....

	if (!ps->io)
	{
		/* writing (marshalling) */
		free(...)
	}
} 

> So it eventually should be rewritten at some point to
> completely obey the rules.
> 

yes.

> the reason for this is that some of the free_xxx() routines are a
little
> > complex.
> 
> Hmm... Example?

the end of spoolss_io_r_getprinterdriver2().

> > um... except for some of the [in out] parameters.
> 
> Hmm... They're realy in_out "on the wire" ??
> How's that possible?

like the ADA IN and OUT specifiers, the parameter is _valid_ on entry to
the function call, and _can_ be modifed _inside_ the function call.

an ADA MSRPC implementation would be a lot cleaner, and an ADA veveloper
would understand these damn issues much better than some of the microsoft
"c" developers.  we'd have some better code to emulate, if they did!  grr.

so, you _must_ send it in as one of the arguments, and you _must_ send it
out.  therefore it is processed in both _q_ and _r_ marshal-code, and must
be malloced  by _q_, server-side and NOT freed by _r_ server-side, and
client-side it should be realloced not malloc, and the CALLER is
responsible for mallocing it and is responsible for freeing it.

uh-oh.  here's one instance where, dare i say it, a dup() might be a good
idea.

reason: you can't mix the memory systems.

what happens if we create our own memory-management for the marshalling /
unmarshalling code, like all other DCE/RPC implementaions have?