OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
unsigned32 *num;
rpc_sm_enable_allocate(&status);
num = (unsigned32*) rpc_sm_allocate(sizeof(unsigned32), &status);
*num = 64;
ptr_test4(binding_h, num, &status);
There are so many ways to use (and misuse) IDL pointers that it would be impossible to
give a complete set of examples. The section on arrays contains more pointer examples.
6.3.4 Context Handles
Context handle semantics vary according to the application role. On the server side, the
semantics are those of a full pointer. To the client application, a context handle has
similar semantics to a fully bound server binding handle, except that the client may not
perform any operations to modify it. To the client it represents a binding to context
maintained by a specific a server instance. Because the context handle may also specify
an object UUID, it may also bind to a specific type manager in the server instance; that
is, a context handle refers to context maintained by a specific type manager in a specific
server instance. It is valid over a series of calls within this scope. To enforce this, a
context handle is intended to be passed as an explicit binding parameter for each
operation that refers to the maintained context. Any attempt to use a context handle
outside this scope will fail. Context handles are described in more detail in the .
6.3.5 Arrays
Array parameters provide an efficient way to pass contiguous blocks of data with little
application overhead. The stubs take care of serializing and reassembling the passed
data transparently to the application. When an application is interested in passing an
entire buffer or some contiguous portion of a buffer synchronously—so that all of the
data is made available to the receiver at the same time—arrays provide the most efficient
mechanism. Pipes provide no advantage unless the data is to be processed
asynchronously.
Arrays may be passed as RPC parameters, but, as in the case of other RPC data, the stubs
need to know the size of data to be marshalled. The simple solution is to declare arrays
of fixed size in the IDL. This can be inefficient however, since array sizes may vary at
runtime, and since not all data in an array may need to be passed on every call.
Therefore, IDL provides a variety of field attributes (max_is, min_is, size_is, last_is,
first_is, and length_is) to permit the size and bounds of the marshalled data to be
determined at runtime. Note that passing a pointer to an array is not any more efficient as
a way to deal with the problem of varying array sizes. Remember that marshalling a
pointer requires marshalling the pointer’s referent, so the array data will be marshalled
anyway. Note also that the IDL language does not permit declaring a pointer to a
varying array.
6− 18 Tandem Computers Incorporated 124246