code for 1.9.19alphas

[Luke Kenneth Casson Leighton]

i'm assuming here that jeremy posted to samba-team out of habit :-)

---------- Forwarded message ----------
Date: Thu, 16 Apr 1998 08:58:50 +1000
From: Luke Kenneth Casson Leighton <lkcl at regent.push.net>
To: Multiple recipients of list <samba-team at samba.anu.edu.au>
Subject: Re: code for 1.9.19alphas

On Wed, 15 Apr 1998, Jeremy Allison wrote:

> 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