Sun RPC and ANSA RPC introduce variable arrays, which are not a base
type of the C language. There are two important consequences of the
introduction of RPC type constructors beyond those available in the
base programming language:
-
Type Conversion
The programmer is now obliged to manage type conversion between the
IDL or XDR type, and whatever is available in run time support (e.g.
alloc/free) for such a function. Since there may be more than one
choice here, this leads to possible divergence in the internal
representations of the external data type (in a non type-safe
way, so programs may crash). In C terms ,this forces the programmer to
use a CAST, which actually hides any error of type conversion from the
meager checking provided in many compilers. Of course, an ubiquitous,
stanard IDL would avert this problem a priori.
-
Buffer Allocation Strategy
A client or server may receive a response or request containing
variables whose storage requirements cannot be known at compile or
initial run time, but only at actual call time. This means that
dynamic storage allocation is required. In the server, any storage
associated with the call or response parameters can be freed by the
RPC dispatcher. However, in the client, either the user is obliged to
provide the storage or they must be given a standard handle for
freeing the RPC reply parameter storage. (They cannot just assume
they can use a standard free function as, for efficiency reasons in
protocol layering implementation, the result parameters may be part of
a larger piece of dynamically allocated storage with preceding header
information). In fact, this latter problem arises even for existing data
types such as strings in any case.
There is also a storage management problem since the space required
for the data type in machine native format may be more than network
buffers provide, so the presentation decoding may not be done in
place (even though it should be done in-line with the network receive
buffer copy code).