coding volunteers needed for msrpc server-side API conversion

Elrond Elrond at
Thu Jan 27 18:53:00 GMT 2000

On Fri, Jan 28, 2000 at 05:29:02AM +1100, Luke Kenneth Casson Leighton wrote:
> 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.

Do I see this right:

xxx_io_q_xxx() is different from xxx_io_r_xxx(), when it
comes to dynamic memory?

As I understood it:
	on the client-side:
		just uses any memory --> no free()
	on the server-side:
		does malloc memory for received data --> malloc()
	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.

> *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.

Okay, that sounds pretty okay.

> > 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



(I'm not (yet) on samba-technical, so please leave a Cc: to me)

More information about the samba-technical mailing list