RPC calls and the RPC API specify directional attributes for their parameters, even though such attributes are not formally supported by C. As a general rule, an [in] parameter is one that must be passed with a meaningful value and an [out] parameter is one whose value will be changed by the call. An [in,out] parameter is therefore one which must have a meaningful value on input and which may be changed on output.
The following table summarizes parameter semantics:
Parameter Semantics
| Semantics | Meaningful value input | Changed on output |
| [in] | yes | no |
| [out] | no | yes |
| [in,out] | yes | yes |
[out] error_status_t *status
The application code then needs to declare a variable such as the following, and pass it as &st to each RPC:
error_status_t st;
When a call allocates storage for an output parameter, it is declared as a pointer to a pointer. For example:
rpc_binding_vector_t **binding_vector
The application follows the same rule as in the status case, declaring a variable such as the following, and then passing this as &binding_vec:
rpc_binding_vector_t *binding_vec
This obeys all the rules for output parameters: the address passed to the call points to valid storage, but the contents of that storage need not contain a meaningful value (in this case, need not be a valid pointer). A simple rule of thumb for output parameters is to declare a variable with one less asterisk than contained in the IDL (or RPC API) declaration and pass its address when calling the operation.
More: