X/Open Corrigenda: U010

Document:
X/Open DCE: Remote Procedure Call (RPC)

X/Open CAE Specification, 08/94
X/Open reference C309

Contents

rpc_ns_entry_inq_resolution
Missing reserved word
Allow parentheses in expressions
Union switch type declaration
Eliminate double declaration in pipe grammar
Declarator grammar errors.
Missing NDR structure alignment rules.

Change number : OSF-1

Source

Open Software Foundation

Title

rpc_ns_entry_inq_resolution

Qualifier

Technical

Rationale

Traversing junctions from CDS to other namespaces (e.g. the registry and DFS namespaces) requires an interface which resolves the cell namespace components of a name and returns partial results.

Change

Chapter 3. Add the rpc_ns_entry_inq_resolution interface to this chapter.

NAME
rpc_ns_entry_inq_resolution - Resolves the cell namespace components of a name and returns partial results

SYNOPSIS
#include <dce/rpc.h>

void rpc_ns_entry_inq_resolution(
unsigned32 entry_name_syntax,
unsigned_char_t *entry_name,
unsigned_char_t **resolved_name,
unsigned_char_t **unresolved_name,
unsigned32 *status
);

PARAMETERS
Input:

entry_name_syntax

An integer value that specifies the syntax of the argument entry_name. (See Appendix C of the AES/DC RPC document for the possible values of this argument.)

The value rpc_c_ns_syntax_default specifies the syntax specified by the RPC_DEFAULT_ENTRY_SYNTAX environment variable. The value rpc_c_ns_syntax_dce corresponds to the name syntax specified in Part 1 of this document.

entry_name
The composite entry name on which the attempted name resolution is to be done.

Input/Output:

resolved_name
Returns a pointer to the resolved portion of the entry name. The resolved_name is null terminated and does not contain trailing component separators (that is, it contains no trailing ``/'' (slash) characters).

If NULL on input, nothing is returned.
unresolved_name
Returns a pointer to the unresolved portion of the entry name. The unresolved_name is a relative name, not containing leading component separators (that is, it contains no leading ``/'' (slash) characters).

If NULL on input, nothing is returned.
Output:

status
Returns the status code from this routine. The status code indicates whether the routine completed successfully, or if not, why not.

Possible status codes and their meanings include (refer to AES/DC Volume \*ERPC, Appendix E for encodings):

rpc_s_ok
Success.
rpc_s_partial_results
The entry name was only partially resolved within the cell namespace and the value of unresolved_name points to the residual of the name.
rpc_s_unsupported_name_syntax
The requested name syntax is not supported.

DESCRIPTION
The rpc_ns_entry_inq_resolution() routine attempts to read a name entry in the cell namespace.
If the read was successful then the full resolution of the entry name is returned.
If the read was not successful due to the entry not being found in the cell namespace, then the partial result of the name resolution is returned, with status code set to rpc_s_partial_results.

If the status code is rpc_s_partial_results and the return parameter resolved_name is non-empty, the contents of resolved_name can be used in subsequent calls to the NSI interface to obtain the binding handle for the name server that controls the namespace in which the entry specified by the value of unresolved_name lies.

The application requires read permission for the name entries that are resolved within the cell namespace.

RETURN VALUES
None.

RELATED INFORMATION
Functions:
rpc_ns_binding_*() interface routines.

CDS remote operations:
cds_Enumerate*(), cds_ReadAttribute() IDL operations.

Change number : OSF-2

Source

Open Software Foundation

Title

Missing reserved word

Qualifier

Technical

Rationale

List is incomplete.

Change

Section 4.6 page 277.

Add the identifier "pointer_default" to the list of reserved words when used in the context of an attribute [this is the second list in the section].

Change number : OSF-3

Source

Open Software Foundation

Title

Allow parentheses in expressions

Qualifier

Technical

Rationale

Rules for parentheses in constant expressions missing from specification.

Change

Section 4.2.7.1, page 241.

Near the bottom of the page, change

from 

<primary_exp> ::= <Integer_literal>
                | <Identifier>
to 
<primary_exp> ::= <Integer_literal>
                | <Identifier>
                | '(' <const_exp> ')'

Change number : OSF-4

Source

Open Software Foundation

Title

Union switch type declaration

Qualifier

Technical

Rationale

An enumeration must be defined before it is used in a (non-encapsulated) union switch type (an enumeration type can be used as a declared type).

Change

-- Section 4.2.12.1, page 245 --

In the production for <switch_type_spec>, replace
|  <enumeration_type>
with 
|  <Identifier>

-- Section 4.2.12.2, page 246 --

At the end of the section, add the following text:

When the <Identifier> alternative is used in the <switch_type_spec> production to declare a switch type, <identifier> must only identify a declared type that resolves to one of the primitive integer type, the char type, the boolean type, or an enum type; it cannot be a pointer, pipe, struct or array type.

-- Section 4.4.1, page 271 --

In the production for (49) <switch_type_spec>, replace
|  <enumeration_type>
with 
|  <Identifier>

-- Section 4.4.2, page 273 --

In the table, <enumeration_type>

Remove 49

Change number : OSF-5

Source

Open Software Foundation

Title

Eliminate double declaration in pipe grammar

Qualifier

Technical

Rationale

The pipe grammar incorrectly allows double sets of declarations.

Change

-- Section 4.2.14.1, page 246 --

Remove the productions:
<pipe_declarator>
<pipe_declarators>

Replace
<pipe_type> ::= pipe <type_spec> <pipe_declarators>
with
<pipe_type> ::= pipe <type_spec>
-- Section 4.4.1 --

Remove the productions:
(83) <pipe_declarator> on page 272
(82) <pipe_declarators> on page 272
-- Section 4.4.2 --

Remove the following rows from the table:
<pipe_declarator> on page 274
<pipe_declarators> on page 274

Change number : OSF-6

Source

Open Software Foundation

Title

Declarator grammar errors.

Qualifier

Technical

Rationale

The grammar for declarators does not match the implementation, nor does it follow the textual description.

Change

-- Section 4.2.8, page 242 --

Remove the productions for
<complex_declarator>
<simple_declarator>

Replace the production for
<declarator>
with
<declarator> ::= <pointer_opt> <direct_declarator>

Add the productions

<direct_declarator> ::= <Identifier>
| ( <declarator> )
| <array_declarator>
| <function_declarator>

-- Section 4.2.15.1., page 247 --

Remove the production for
<array_bounds_list>

Replace the production for:
<array_declarator>
with
<array_declarator> ::= <direct_declarator> <array_bounds_declarator>

In the production <array_bound> replace
| <Integer_literal>
with
| <integer_const_expr>

-- Section 4.2.20.1, page 253 --

Remove the production
"<ptr_declarator>"

Add the productions:
<declarator> ::= <pointer_opt> <direct_declarator>
<pointer_opt> ::= [<pointer>]
<pointer> ::= *...

Replace the string
<ptr_declarator>
with the string
pointer declaration
on pages 253 through 255.

-- Section 4.2.24.1, page 260 --

Replace the production for:
<function_ptr_declarator>
with
<function_declarator> ::= <direct_declarator> <param_declarators>

-- Section 4.4.1 --

Remove the productions:
(24) <simple_declarator> on page 270
(25) <complex_declarator> on page 270
(60) <array_bounds_list> on page 271
(70) <ptr_declarator> on page 272

Replace the production for

(23) <declarator>
with
(23) <declarator> ::= <pointer_opt> <direct_declarator>

Replace the production for:

(59) <array_declarator>
with
(59) <array_declarator> ::= <direct_declarator> <array_bounds_declarator>

Replace the production for:
(79) <function_ptr_declarator> with
(79) <function_declarator> ::= <direct_declarator> <param_declarators>

In the production (63) <array_bound> replace
| <Integer_literal>
with
| <integer_const_expr>

Add the productions:
(70) <pointer_opt> ::= [<pointer>]
(70.1) <pointer> ::= *...
(24) <direct_declarator> ::= <Identifier>
| ( <declarator> )
| <array_declarator>
| <function_declarator>

-- Section 4.4.2 --
Remove the following rows from the table:
<simple_declarator> on page 273
<complex_declarator> on page 273
<ptr_declarator> on page 274
<array_bounds_list> on page 274
<function_ptr_declarator> on page 273

Change the following entries to the table:

<declarator> (23) 21, 24, 75
<array_declarator> (59) 24
<Integer_literal> Remove 63
<integer_const_expr> Add 63

Add the following entries to the table:

<pointer_opt> (70) 23
<pointer> (70.1) 70
<direct_declarator> (24) 23, 59, 79
<function_declarator> (79) 24

Change number : OSF-7

Source

Open Software Foundation

Title

Missing NDR structure alignment rules.

Qualifier

Technical

Rationale

The rules for aligning structures in NDR is missing.

Change

Section 14.3.5, page 576.
Add a new section:

14.3.1.1 Alignment of Constructed Types

NDR enforces NDR alignment of structured data. As with primitive data types, an alignment, `n', is determined for the structure. Where necessary, an alignment gap of octets of unspecified value preceeds the data in the NDR octet stream. This gap is the smallest size sufficient to align the first field of the structure on an NDR octet stream index of `n'.

The rules for calculating the alignemnt of constructed types are:

- If a conformant structure (that is, a conformant or varying- -conformant array, or a structure containing a conformant or varying-conformant array) is embedded in the constructed type, and this is the outer-most containing constructed type (this structure is not contained in another structure), then the size information from the contained conformant structure is positioned so that it preceeds both the containing constructed type (see section 14.3.6 for details) and any alignment gap for the constructed type. The size information is itself aligned according to the alignment rules for primitive data types. The data of the constructed type is then aligned according to the alignment rules for the constructed type. In other words, the size information preceeds the structure and is aligned independently of the structure alignment.

- The alignment of a structure in the octet stream is the largest of the alignments of the fields it contains. These fields may also be constructed types. The same alignment rules apply recursively to nested constructed types.

- The fields within the structure are aligned according to the following rules:
+ scalar primitives are aligned according to section 14.2.2.
+ pointer alignment is always modulo 4.
+ struct alignment is determined by recursive application of these rules.
+ array alignment is the largest alignment of the array element type and the size information type, if any.
+ union alignment is the largest alignment of the union discriminator and all of the union arms.

NOTE:
The above notions of the union alignment and of the array alignment apply only for calculating the NDR alignment of a struct and don't apply to the actual NDR alignment of a union or an array. For example, the NDR alignment of a union is determined by the tag type and the arm actually to be transmitted, not the largest of the union arms. Similarly, the NDR alignment of an array is determined by the element type alignment, which would be the largest arm of the union for the case of an array of unions.

If you can't find the information you need, please contact X/Open at any of its offices.

Copyright X/Open Company Limited, © 1995