coding volunteers needed for msrpc server-side API conversion
Elrond
Elrond at Wunder-Nett.org
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:
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.
> *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
Okay.
Elrond
(I'm not (yet) on samba-technical, so please leave a Cc: to me)
More information about the samba-technical
mailing list