OSF DCE Application Development Guide--Introduction and Style Guide
RPC Parameters
As a matter of programming style, these types have the advantage that the size of the
declared data items is explicitly stated. For this reason their use in both IDL declarations
and application C code is recommended. Note also that the following IDL and C
typedefs are also made available by implementations a convenient portable declaration
for status parameters:
typedef unsigned long error_status_t;
typedef idl_ulong_int error_status_t;
6.3.2 Character Handling
When passed as an RPC paramter, the IDL char type is automatically subject to ASCII-
EBCDIC conversion, depending on the character encodings used by the client and server
machines. Therefore, the contents of a char type may not be the same for the sender and
receiver. This allows clients and servers to maintain the same semantics when passing
characters between machines that use different encodings. For example, the character a
is represented by a byte with the value 61h on an ASCII machine, and a byte with the
value 81h on an EBCDIC machine. RPC automatically makes the conversion so that a
character parameter that prints as a on the client machine also prints as a when recieved
by the server.
However, if what your application really intends is to pass a byte with the value 61h from
client to server, such translation is clearly not what you want. To avoid this potential
problem, when passing byte data with noncharacter semantics, use the IDL byte type.
Also note that IDL provides three international character types for use with nonASCII,
nonEBCDIC character sets: ISO_LATIN_1, ISO_MULTI_LINGUAL, and ISO_UCS.
To ensure portability, your application should use these types to declare character data in
one of these sets.
6.3.3 Pointers
RPC pointers differ from local pointers in one key respect: there is no shared address
space between client and server. This means that the stubs need to marshall the pointed-
to data itself. To do so, the stubs must be able to dereference any pointer passed as a
parameter. This means that a pointer, even if it does not point at useful data, must be
initialized either to NULL or to a valid address before it is passed as a parameter. This
behavior may be counter-intuitive for programmers used to local procedure calls, where
pointers may be freely passed whether they have been initialized or not, and is a common
source of programming grief for remote procedure calls.
To be able to marshall pointer referents, the stubs need to know, either at compile time or
at runtime, how much data to transmit; that is, they need to know the size of the pointed
to object. This can require a good deal of work on the part of the stubs in the case of
varying or conformant arrays and objects like linked lists.
124246 Tandem Computers Incorporated 6−9