coding volunteers needed for msrpc server-side API conversion
Elrond at Wunder-Nett.org
Thu Jan 27 20:26:15 GMT 2000
On Fri, Jan 28, 2000 at 07:06:35AM +1100, Luke Kenneth Casson Leighton wrote:
> On Thu, 27 Jan 2000, Elrond wrote:
> > On Fri, Jan 28, 2000 at 06:39:46AM +1100, Luke Kenneth Casson Leighton wrote:
> > > > In cli_*.c we do:
> > > >
> > > > xxx_xxx(const foo in, foo **out)
> > > > xxx_make_q_xxx(in) /* this one dups all the neccessary things */
> > >
> > > elrond,
> > > k
> > > thi is not acceptable for the SPOOLSS functions, which pass in a
> > > stupid-wasted buffer as an [in out] parameter.
> > 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
So in the long run, that should be converted !?
> > 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
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();
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.
- xxx_io_xxx mallocs, when it receives.
- make_xxx doesn't dup() anything.
- so xxx_io_xxx may not realloc when it sends (this is
More information about the samba-technical