libmsrpc for Samba 3

derrell at derrell at
Wed Jul 20 16:29:21 GMT 2005

"Gerald (Jerry) Carter" <jerry at> writes:

> Chris Nicholls wrote:
> | This 'control block' structure has grown on me since
> | i first looked at this thread last night. It definately makes
> | for much more readable code  and makes it really easy to
> | pass a number of parameters out of a function (as a lot
> | of rpc operations seem to do).  The only question I
> | have right now is what happens if an application
> | have right now is what happens if an application
> | developer forgets to initialize a particular in.*
> | member?
> You're screwed.  It's a programmer error and the compiler
> cannot help you out.  That's one reason why I'm a little
> hesitant on this.  Although we all have been consolidating
> parameters to passing a structure pointer to keep function
> formal parameters lists short.

I'm not entirely convinced that your concern is justified.  With a control
block structure to initialize, my experience has been that programmers will
tend to enumerate all of the structure fields in their code, and initialize
all of them.

That not withstanding, doing something like this may help:

    initialize_operation(OP_SPOOLSS_OPENPRINTER, &op);       = talloc_asprintf(ctx,
                              dcerpc_server_name(ctx->p));          = NULL; NULL;       = 0;
    op.out.handle           = &ctx->server_handle;

    status = dcerpc_spoolss_OpenPrinter(ctx->p, ctx, &op);

The initialize_operation() function can either set reasonable default values
for each of the fields in "op" or set each parameter to an illegal value so
that uninitialized fields can be caught in dcerpc_spoolss_OpenPrinter().

Note that initialize_operation() specifically does NOT take parameters to fill
in the structure.  That would, of course, eliminate the utility of the control
block.  The function simply initialize all fields to reasonable defaults or
illegal values.


More information about the samba-technical mailing list