Enhancements to the Language


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Programming BEA Tuxedo ATMI Applications Using TxRPC \| Local Topics \| Previous Topic \| Next Topic \| Contents

The following are enhancements to the X/OPEN RPC specification. In most cases, the language has been enhanced to more closely follow the C language, simplifying the porting of existing interfaces (converting from ANSI C to IDL prototypes).

In the X/OPEN specification, character constants and character strings are limited to the portable set, that is space (0x20) through tilde (0x7e). Other characters in the character set (0x01 through 0xff) are allowed, as in OSF DCE RPC.
As in C, the following operators are treated as punctuators.
```
|| && ? | & _ == != = << >> <= >= < > + - % ! ~
```
This means that white space need not follow or precede identifiers or numbers if preceded or followed by one of these tokens. (The IDL specification requires white space, as in a = b + 3, instead of allowing a=b+3.) This also seems to be the behavior of the OSF DCE IDL compiler.
The published X/OPEN specification restricts field and parameter names from matching type names. This restriction effectively puts all names in a single name space. This restriction does not match C, C++, or the OSF IDL compiler, and is not enforced.
The X/OPEN specification does not allow anonymous enumerations as parameter or function results and does not allow anonymous structures or unions as the targets of pointers. Each of these is allowed by the OSF DCE IDL compiler. These restrictions are not enforced; in each case, a name, based on the interface name and version, is generated for use during marshalling.
Enumeration values (constants) may be used in integer constant expressions (as in C). This also seems to be the behavior of the DCE IDL compiler.
As currently defined in the X/OPEN RPC specification, the grammar does not allow for a pointer in front of an operation declaration, for example:
```
long *op(void);
```
nor does it allow for structure or union returns. While this could be considered correct (everything could be hidden in a defined type), the DCE IDL compiler and, of course, C compiler allow a much richer operation return. The supported grammar will be the following:
```
[operation_attributes] <type_spec> <declarator>
```
where <declarator> must contain a <function_declarator>. (If a <function_declarator> does not exist, then a variable is declared, which results in an error.) Declaring an array of operations or an operation returning an array (both allowed by this grammar) will be detected and flagged as an error.
The <ACS_type_declaration> takes <ACS_named_type> values, just as the IDL <type_declaration> takes a list of declarators. This seems to be the behavior of the DCE IDL compiler.
Fielded buffers created and manipulated with the Field Manipulation Language (FML) are an integral part of many BEA Tuxedo ATMI applications. Fielded buffers are supported as a new base type in the IDL. They are indicated by the keywords FBFR for 16-bit buffers and FBFR32 for 32-bit buffers and must always be defined as a pointer (for example, FBFR * or FBFR32 *). A fielded buffer cannot be defined as the base type in a typedef. They can be used in structure fields and as parameters. They can be used as the base type in an array or pointer (either full or reference pointer). However, conformant and varying arrays of fielded buffers are not supported.
There are several restrictions in the OSF IDL compiler that are not documented in the AES or X/OPEN RPC specification. These are enforced in the BEA Tuxedo IDL compiler:

Enhancements that May Limit Portability

There are four additional BEA Tuxedo ATMI enhancements to the X/OPEN RPC specification that, while making the specification more C-like, are not supported in the OSF DCE IDL compiler and thus have the effect of limiting portability of the IDL file:

String concatenation is supported (as in ANSI C). That is:
```
const char *str = "abc" "def";
```
is treated the same as
```
const char *str = "abcdef";
```
Escaped newlines are allowed in string constants. That is:
```
const char *str = "abc\
 def";
```
is treated the same as
```
const char *str = "abcdef";
```
Enumeration values may also be used in union cases and are treated as integers (that is, automatic conversion is provided as in C).
The restriction that the type of each <union_case_label> must be that specified by the <switch_type_spec> will not be enforced. Instead, the type will be coerced as is done with case statements in a C switch statement.