coding volunteers needed for msrpc server-side API conversion
Luke Kenneth Casson Leighton
lkcl at samba.org
Thu Jan 27 20:57:27 GMT 2000
> > > Well, that sounds like spoolss isn't doing _any_ dynamic
> > > memory, so there isn't really a conflict / problem here.
> > strictly speaking? you're right. the malloc / freeing is being done by
> > the marshalling /. unmarshalling code.
> > however, jean-francois' implementation does (and ignores the unmarshalled
> > BUFFER*)
> So in the long run, that should be converted !?
yes. probably to type-cast the already-malloc'd data to the appropriate
structure, rather than internally malloc it and then copy it in!
> > > All my arguments are for dynamic memory only. For the rest,
> > > there's no need to dup() things.
> > the static-sized structures? correct.
> > even for the dynamic memory ones, it's not _really_ ok to dup() an list or
> > array structure, when it could be a megabyte of contiguous memory.
> Okay, that sounds right. Let me see, if I can modify my
> "model" to do this:
> In cli_*.c we do:
> xxx_xxx(const foo in, foo **out)
> xxx_make_q_xxx(in) /* this one "remembers" the pointers */
> xxx_io_q_xxx() /* this one USEs the pointers */
> xxx_io_r_xxx(&x) /* mallocs appropiate memory */
> *out = x
yep. looks good, even for dynamic memory and static memory cases.
the CALLER of xxx_xxx(foo in , foo **out) is responsible for freeing *out
(x). see NetApiBufferFree() in ms code. we really should be implementing
this type of system.
> In srv_*.c we have:
> xxx_io_q_xxx(&x) /* will malloc memory for x, as we're receiving */
> _xxx_xxx(x, &y) /* will USE x, malloc y */
> free(x); /* we don't need it any more */
> /* y is the answer */
> xxx_make_r_xxx(y) /* will "remember" y */
> xxx_io_r_xxx() /* will USE the y */
> And in daemon/*_real.c
> _xxx_xxx(const foo in, foo **out)
> /* this function does real work */
> /* will only USE in */
> /* will malloc memory for out */
> *out = malloc();
yep!!! you notice that if you cut out the marshalling and unmarshalling
bits, the xxx_xxx() memory alliocation and usage and the _xxx_xxx() memory
allcation and usage are EXACTLY the same?
that's the way it _should_ be.
> Since I haven't looked at the whole spoolss-code, I currently can't
> tell, if it could fit in this model.
> But the main idea is now:
> - xxx_io_xxx doesn't do _any_ free itself.
umm, well, i actually have freeing() in some of the code when it's used in
server-side, so the logic obeys the Rules above, but it just doesn't
_look_ like it obeys the rules.
the reason for this is that some of the free_xxx() routines are a little
> - xxx_io_xxx mallocs, when it receives.
> - make_xxx doesn't dup() anything.
correct. these rules are currently broken by some of the code to
make_q_xxx() being combined with mallocs() as outlined in Rules above.
what is worse is that make_q_xxx() sometimes takes char* or char** and
consttcucts UNISTR* or UNISTR**, which is _Really_ bad!
> - so xxx_io_xxx may not realloc when it sends (this is
> anyway good)
um... except for some of the [in out] parameters.
More information about the samba-technical