code for 1.9.19alphas
Christopher R. Hertel
crh at NTS.Umn.EDU
Thu Apr 16 16:14:00 GMT 1998
>
> ok, further comments (this is posted to samba-technical, too).
>
> instead of a separate free_xxx function, add an extra BOOL parameter to
> make_xxxx.
>
> if True, malloc. if False, free. call other make_xxxx sub-functions with
> the extra BOOL parameter too.
>
> reason: this will keep mallocs and frees in the same place. this is
> important so that future development doesn't get out of step (resulting in
> loss of memory stuff).
>
> there is a precedent for this already: the prs_xxx functions have a BOOL
> io parameter.
>
> if True, write into stream. if False, read out of stream (possibly
> vice-versa :-)
>
> luke
>
> > > Luke,
> > >
> > > I intend to start hacking on your DCE/RPC code
> > > in the main branch - just wanted to give you fair
> > > warning :-).
> > >
> > > Some of the things I intend to do :
> > >
> > > 1). Tidy up the structures that say :
> > >
> > > uint32 XXXX /* undocumented buffer pointer */
> > >
> > > so that they get the address of the thing
> > > they point to added into the rather than
> > > the static '4' or '2' etc.
> >
> > good idea.
> >
> > > 2). Lots of the code looks like (an example
> > > from svr_lsa.c):
> > >
> > > --------------start fragment----------------------
> > > /***************************************************************************
> > > lsa_reply_lookup_sids
> > > ***************************************************************************/
> > > static void lsa_reply_lookup_sids(prs_struct *rdata,
> > > int num_entries, DOM_SID2 sid[MAX_LOOKUP_SIDS],
> > > char *dom_name, char *dom_sid,
> > > char *other_sid1, char *other_sid2, char *other_sid3)
> > > {
> > > LSA_R_LOOKUP_SIDS r_l;
> > > DOM_R_REF ref;
> > > LSA_TRANS_NAME_ENUM names;
> > > uint32 mapped_count = 0;
> > >
> > > /* set up the LSA Lookup SIDs response */
> > > make_dom_ref(&ref, dom_name, dom_sid, other_sid1, other_sid2, other_sid3);
> > > make_lsa_trans_names(&names, num_entries, sid, &mapped_count);
> > > make_reply_lookup_sids(&r_l, &ref, &names, mapped_count, 0x0);
> > >
> > > /* store the response in the SMB stream */
> > > lsa_io_r_lookup_sids("", &r_l, rdata, 0);
> > > }
> > >
> > > ----------------end fragment---------------------------
> > > Now most of the data is statically allocated (I'm thinking
> > > of the UNICODE strings stuff mainly.
> > >
> > > What I indend to do is change it to something that looks
> > > like :
> > >
> > >
> > > static void lsa_reply_lookup_sids(prs_struct *rdata,
> > > int num_entries, DOM_SID2 sid[MAX_LOOKUP_SIDS],
> > > char *dom_name, char *dom_sid,
> > > char *other_sid1, char *other_sid2, char *other_sid3)
> > > {
> > > LSA_R_LOOKUP_SIDS r_l;
> > > DOM_R_REF ref;
> > > LSA_TRANS_NAME_ENUM names;
> > > uint32 mapped_count = 0;
> > >
> > > /* set up the LSA Lookup SIDs response */
> > > make_dom_ref(&ref, dom_name, dom_sid, other_sid1, other_sid2, other_sid3);
> > > make_lsa_trans_names(&names, num_entries, sid, &mapped_count);
> > > make_reply_lookup_sids(&r_l, &ref, &names, mapped_count, 0x0);
> > >
> > > /* store the response in the SMB stream */
> > > lsa_io_r_lookup_sids("", &r_l, rdata, 0);
> > >
> > >
> > > /* Now free the stuff we allocated & linearized */
> > > free_dom_ref(....);
> > > free_lsa_trans_names(...);
> > > free_reply_lookup_sids(...);
> > > }
> > >
> > > Essentially - pair each 'make_xxxx' with a 'free_xxx'
> > > and change the make_xxx() calls to do malloc's for
> > > all the potentially large data.
> >
> > the thought of doing this makes me go wobbly at the knees.
> >
> > > This will get rid of the max unicode string stuff,
> > > and make things dynamically allocated & freed
> > > instead.
> >
> > an alternative. instead of a static structure, have a higher order
> > function table. in the example above, the functions would be
> >
> > init_sid_table()
> > set_sid_entry(); next_sid_entry();
> > close_sid_table()
> >
> > luke
> >
>
--
Christopher R. Hertel -)----- University of Minnesota
crh at nts.umn.edu Networking and Telecommunications Services
More information about the samba-technical
mailing list