coding volunteers needed for msrpc server-side API conversion

[Luke Kenneth Casson Leighton]

On Thu, 27 Jan 2000, Elrond wrote:

> On Fri, Jan 28, 2000 at 04:20:29AM +1100, Luke Kenneth Casson Leighton wrote:
> > i'd suggest starting with lsa_close().
> 
> Okay, sounds more easier. Right.
> 
> > examine wkssvc/srv_wkssvc_nt.c, samr/srv_samr_passdb.c for comments (esp.
> > the ones at the bottom of the samr fn).
> 
> Yeah, I saw them, I think, I got the basic idea behind the
> conversion. After some time I liked it, also I'm still
> thinking about the right "model" for dynamic memory. (who
> has to malloc what, and who will free it)

OK.  The Rules Are:

1) the rules change as we develop code

2) client-side is different from server-side

3) server-side, the xxx_io_q_xxx() routines should malloc any memory.
once processed (incoming arguments), the memory should be freed.
the proccesING (outgoing arguments) should malloc any memory.
the xxx_io_r_xxx() should free the outgoing arguments.

4) client-side, the CALLER mallocs memory.  the xxx_io_q_xxx() routines
USE that malloc'd memory. on receipt of incoming arguments
(xxx_io_r_xxx()), which should be mallocd or in the case of [in out]
arguments it should be Realloc'd, the CALLER frees all dynamically
allocated memory.

*SOME* of the functions can take pointers-to-stack-based arguments.  in
this case, the xxx_io_r_xxx() routines should NOT, when used client-side,
realloc or malloc [in out] arguments.

i think the rules are:

- if it's a fixed-size (struct or union), you can make it stack-based,
regardless of whether it's an in, out or [in out].

- if it's a variable-size (list, array etc), you can't make it
stack-based.
 
> How do you want the new lsarcpd/*.c be called? It would be
> nice, if you could create one, so I have something to work
> on.

oh, i don't know!  i _should_ rename lsarpcd/srv_lsa.c to
lsarpc/srv_lsa_nt.c.

*sigh*. call it srv_lsa_nt.c