As per Relevance of the word represent, we have this rfc below:
Network Working Group R.
Request for Comments: 1832 Sun
Category: Standards Track August 1995
XDR: External Data Representation
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document describes the External Data Representation
(XDR) protocol as it is currently deployed and accepted
TABLE OF
1. INTRODUCTION 2
2. BASIC BLOCK SIZE 2
3. XDR DATA TYPES 3
3.1 Integer 3
3.2 Unsigned Integer 4
3.3 Enumeration 4
3.4 Boolean 4
3.5 Hyper Integer and Unsigned Hyper Integer 4
3.6 Floating-point 5
3.7 Double-precision Floating-point 6
3.8 Quadruple-precision Floating-point 7
3.9 Fixed-length Opaque Data 8
3.10 Variable-length Opaque Data 8
3.11 String 9
3.12 Fixed-length Array 10
3.13 Variable-length Array 10
3.14 Structure 11
3.15 Discriminated Union 11
3.16 Void 12
3.17 Constant 12
3.18 Typedef 13
3.19 Optional-data 14
3.20 Areas for Future Enhancement 15
4. DISCUSSION 15
5. THE XDR LANGUAGE SPECIFICATION 17
5.1 Notational Conventions 17
Srinivasan Standards Track [Page 1]
RFC 1832 XDR: External Data Representation Standard August 1995
5.2 Lexical Notes 17
5.3 Syntax Information 18
5.4 Syntax Notes 19
6. AN EXAMPLE OF AN XDR DATA DESCRIPTION 20
7. TRADEMARKS AND OWNERS 21
APPENDIX A: ANSI/IEEE Standard 754-1985 22
APPENDIX B: REFERENCES 24
Security Considerations 24
Author's Address 24
1.
XDR is a standard for the description and encoding of data. It
useful for transferring data between different
architectures, and has been used to communicate data between
diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*.
XDR fits into the ISO presentation layer, and is roughly analogous
purpose to X.409, ISO Abstract Syntax Notation. The major
between these two is that XDR uses implicit typing, while X.409
explicit typing
XDR uses a language to describe data formats. The language can
be used only to describe data; it is not a programming language
This language allows one to describe intricate data formats in
concise manner. The alternative of using graphical
(itself an informal language) quickly becomes incomprehensible
faced with complexity. The XDR language itself is similar to the
language [1], just as Courier [4] is similar to Mesa. Protocols
as ONC RPC (Remote Procedure Call) and the NFS* (Network File System
use XDR to describe the format of their data
The XDR standard makes the following assumption: that bytes (
octets) are portable, where a byte is defined to be 8 bits of data
A given hardware device should encode the bytes onto the
media in such a way that other hardware devices may decode the
without loss of meaning. For example, the Ethernet*
suggests that bytes be encoded in "little-endian" style [2], or
significant bit first
2. BASIC BLOCK
The representation of all items requires a multiple of four bytes (
32 bits) of data. The bytes are numbered 0 through n-1. The
are read or written to some byte stream such that byte m
precedes byte m+1. If the n bytes needed to contain the data are
a multiple of four, then the n bytes are followed by enough (0 to 3)
residual zero bytes, r, to make the total byte count a multiple of 4.
Srinivasan Standards Track [Page 2]
RFC 1832 XDR: External Data Representation Standard August 1995
We include the familiar graphic box notation for illustration
comparison. In most illustrations, each box (delimited by a
sign at the 4 corners and vertical bars and dashes) depicts a byte
Ellipses (...) between boxes show zero or more additional bytes
required
+--------+--------+...+--------+--------+...+--------+
| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |
+--------+--------+...+--------+--------+...+--------+
|<-----------n bytes---------->|<------r bytes------>|
|<-----------n+r (where (n+r) mod 4 = 0)>----------->|
3. XDR DATA
Each of the sections that follow describes a data type defined in
XDR standard, shows how it is declared in the language, and
a graphic illustration of its encoding
For each data type in the language we show a general
declaration. Note that angle brackets (< and >)
variablelength sequences of data and square brackets ([ and ])
fixed-length sequences of data. "n", "m" and "r" denote integers
For the full language specification and more formal definitions
terms such as "identifier" and "declaration", refer to section 5:
"The XDR Language Specification".
For some data types, more specific examples are included. A
extensive example of a data description is in section 6: "An
of an XDR Data Description".
3.1
An XDR signed integer is a 32-bit datum that encodes an integer
the range [-2147483648,2147483647]. The integer is represented
two's complement notation. The most and least significant bytes
0 and 3, respectively. Integers are declared as follows
int identifier
(MSB) (LSB
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 |
+-------+-------+-------+-------+
<------------32 bits------------>
Srinivasan Standards Track [Page 3]
RFC 1832 XDR: External Data Representation Standard August 1995
3.2. Unsigned
An XDR unsigned integer is a 32-bit datum that encodes a
integer in the range [0,4294967295]. It is represented by
unsigned binary number whose most and least significant bytes are 0
and 3, respectively. An unsigned integer is declared as follows
unsigned int identifier
(MSB) (LSB
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | UNSIGNED
+-------+-------+-------+-------+
<------------32 bits------------>
3.3
Enumerations have the same representation as signed integers
Enumerations are handy for describing subsets of the integers
Enumerated data is declared as follows
enum { name-identifier = constant, ... } identifier
For example, the three colors red, yellow, and blue could
described by an enumerated type
enum { RED = 2, YELLOW = 3, BLUE = 5 } colors
It is an error to encode as an enum any other integer than those
have been given assignments in the enum declaration
3.4
Booleans are important enough and occur frequently enough to
their own explicit type in the standard. Booleans are declared
follows
bool identifier
This is equivalent to
enum { FALSE = 0, TRUE = 1 } identifier
3.5 Hyper Integer and Unsigned Hyper
The standard also defines 64-bit (8-byte) numbers called
integer and unsigned hyper integer. Their representations are
obvious extensions of integer and unsigned integer defined above
Srinivasan Standards Track [Page 4]
RFC 1832 XDR: External Data Representation Standard August 1995
They are represented in two's complement notation. The most
least significant bytes are 0 and 7, respectively.
declarations
hyper identifier; unsigned hyper identifier
(MSB) (LSB
+-------+-------+-------+-------+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
+-------+-------+-------+-------+-------+-------+-------+-------+
<----------------------------64 bits---------------------------->
HYPER
UNSIGNED HYPER
3.6 Floating-
The standard defines the floating-point data type "float" (32 bits
4 bytes). The encoding used is the IEEE standard for
single-precision floating-point numbers [3]. The following
fields describe the single-precision floating-point number
S: The sign of the number. Values 0 and 1 represent positive
negative, respectively. One bit
E: The exponent of the number, base 2. 8 bits are devoted to
field. The exponent is biased by 127.
F: The fractional part of the number's mantissa, base 2. 23
are devoted to this field
Therefore, the floating-point number is described by
(-1)**S * 2**(E-Bias) * 1.
It is declared as follows
float identifier
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | SINGLE-
S| E | F | FLOATING-POINT
+-------+-------+-------+-------+
1|<- 8 ->|<-------23 bits------>|
<------------32 bits------------>
Just as the most and least significant bytes of a number are 0 and 3,
the most and least significant bits of a single-precision floating
point number are 0 and 31. The beginning bit (and most
Srinivasan Standards Track [Page 5]
RFC 1832 XDR: External Data Representation Standard August 1995
bit) offsets of S, E, and F are 0, 1, and 9, respectively. Note
these numbers refer to the mathematical positions of the bits,
NOT to their actual physical locations (which vary from medium
medium).
The IEEE specifications should be consulted concerning the
for signed zero, signed infinity (overflow), and denormalized
(underflow) [3]. According to IEEE specifications, the "NaN" (not
number) is system dependent and should not be interpreted within
as anything other than "NaN".
3.7 Double-precision Floating-
The standard defines the encoding for the double-precision floating
point data type "double" (64 bits or 8 bytes). The encoding used
the IEEE standard for normalized double-precision floating-
numbers [3]. The standard encodes the following three fields,
describe the double-precision floating-point number
S: The sign of the number. Values 0 and 1 represent positive
negative, respectively. One bit
E: The exponent of the number, base 2. 11 bits are devoted
this field. The exponent is biased by 1023.
F: The fractional part of the number's mantissa, base 2. 52
are devoted to this field
Therefore, the floating-point number is described by
(-1)**S * 2**(E-Bias) * 1.
It is declared as follows
double identifier
+------+------+------+------+------+------+------+------+
|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
S| E | F |
+------+------+------+------+------+------+------+------+
1|<--11-->|<-----------------52 bits------------------->|
<-----------------------64 bits------------------------->
DOUBLE-PRECISION FLOATING-
Just as the most and least significant bytes of a number are 0 and 3,
the most and least significant bits of a double-precision floating
point number are 0 and 63. The beginning bit (and most
bit) offsets of S, E , and F are 0, 1, and 12, respectively.
Srinivasan Standards Track [Page 6]
RFC 1832 XDR: External Data Representation Standard August 1995
that these numbers refer to the mathematical positions of the bits
and NOT to their actual physical locations (which vary from medium
medium).
The IEEE specifications should be consulted concerning the
for signed zero, signed infinity (overflow), and denormalized
(underflow) [3]. According to IEEE specifications, the "NaN" (not
number) is system dependent and should not be interpreted within
as anything other than "NaN".
3.8 Quadruple-precision Floating-
The standard defines the encoding for the quadruple-
floating-point data type "quadruple" (128 bits or 16 bytes).
encoding used is designed to be a simple analog of of the
used for single and double-precision floating-point numbers using
form of IEEE double extended precision. The standard encodes
following three fields, which describe the quadruple-
floating-point number
S: The sign of the number. Values 0 and 1 represent positive
negative, respectively. One bit
E: The exponent of the number, base 2. 15 bits are devoted
this field. The exponent is biased by 16383.
F: The fractional part of the number's mantissa, base 2. 112
are devoted to this field
Therefore, the floating-point number is described by
(-1)**S * 2**(E-Bias) * 1.
It is declared as follows
quadruple identifier
+------+------+------+------+------+------+-...--+------+
|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5| ... |byte15|
S| E | F |
+------+------+------+------+------+------+-...--+------+
1|<----15---->|<-------------112 bits------------------>|
<-----------------------128 bits------------------------>
QUADRUPLE-PRECISION FLOATING-
Just as the most and least significant bytes of a number are 0 and 3,
the most and least significant bits of a quadruple-
floating-point number are 0 and 127. The beginning bit (and
Srinivasan Standards Track [Page 7]
RFC 1832 XDR: External Data Representation Standard August 1995
significant bit) offsets of S, E , and F are 0, 1, and 16,
respectively. Note that these numbers refer to the
positions of the bits, and NOT to their actual physical
(which vary from medium to medium).
The encoding for signed zero, signed infinity (overflow),
denormalized numbers are analogs of the corresponding encodings
single and double-precision floating-point numbers [5], [6].
"NaN" encoding as it applies to quadruple-precision floating-
numbers is system dependent and should not be interpreted within
as anything other than "NaN".
3.9 Fixed-length Opaque
At times, fixed-length uninterpreted data needs to be passed
machines. This data is called "opaque" and is declared as follows
opaque identifier[n];
where the constant n is the (static) number of bytes necessary
contain the opaque data. If n is not a multiple of four, then the
bytes are followed by enough (0 to 3) residual zero bytes, r, to
the total byte count of the opaque object a multiple of four
0 1 ...
+--------+--------+...+--------+--------+...+--------+
| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |
+--------+--------+...+--------+--------+...+--------+
|<-----------n bytes---------->|<------r bytes------>|
|<-----------n+r (where (n+r) mod 4 = 0)------------>|
FIXED-LENGTH
3.10 Variable-length Opaque
The standard also provides for variable-length (counted) opaque data
defined as a sequence of n (numbered 0 through n-1) arbitrary
to be the number n encoded as an unsigned integer (as
below), and followed by the n bytes of the sequence
Srinivasan Standards Track [Page 8]
RFC 1832 XDR: External Data Representation Standard August 1995
Byte m of the sequence always precedes byte m+1 of the sequence,
byte 0 of the sequence always follows the sequence's length (count).
If n is not a multiple of four, then the n bytes are followed
enough (0 to 3) residual zero bytes, r, to make the total byte
a multiple of four. Variable-length opaque data is declared in
following way
opaque identifier;
opaque identifier<>;
The constant m denotes an upper bound of the number of bytes that
sequence may contain. If m is not specified, as in the
declaration, it is assumed to be (2**32) - 1, the maximum length
The constant m would normally be found in a protocol specification
For example, a filing protocol may state that the maximum
transfer size is 8192 bytes, as follows
opaque filedata<8192>;
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
|<----n+r (where (n+r) mod 4 = 0)---->|
VARIABLE-LENGTH
It is an error to encode a length greater than the maximum
in the specification
3.11
The standard defines a string of n (numbered 0 through n-1)
bytes to be the number n encoded as an unsigned integer (as
above), and followed by the n bytes of the string. Byte m of
string always precedes byte m+1 of the string, and byte 0 of
string always follows the string's length. If n is not a multiple
four, then the n bytes are followed by enough (0 to 3) residual
bytes, r, to make the total byte count a multiple of four.
byte strings are declared as follows
string object;
string object<>;
The constant m denotes an upper bound of the number of bytes that
string may contain. If m is not specified, as in the
Srinivasan Standards Track [Page 9]
RFC 1832 XDR: External Data Representation Standard August 1995
declaration, it is assumed to be (2**32) - 1, the maximum length
The constant m would normally be found in a protocol specification
For example, a filing protocol may state that a file name can be
longer than 255 bytes, as follows
string filename<255>;
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
|<----n+r (where (n+r) mod 4 = 0)---->|
It is an error to encode a length greater than the maximum
in the specification
3.12 Fixed-length
Declarations for fixed-length arrays of homogeneous elements are
the following form
type-name identifier[n];
Fixed-length arrays of elements numbered 0 through n-1 are encoded
individually encoding the elements of the array in their
order, 0 through n-1. Each element's size is a multiple of
bytes. Though all elements are of the same type, the elements
have different sizes. For example, in a fixed-length array
strings, all elements are of type "string", yet each element
vary in its length
+---+---+---+---+---+---+---+---+...+---+---+---+---+
| element 0 | element 1 |...| element n-1 |
+---+---+---+---+---+---+---+---+...+---+---+---+---+
|<--------------------n elements------------------->|
FIXED-LENGTH
3.13 Variable-length
Counted arrays provide the ability to encode variable-length arrays
homogeneous elements. The array is encoded as the element count n (
unsigned integer) followed by the encoding of each of the array'
elements, starting with element 0 and progressing through element n- 1.
The declaration for variable-length arrays follows this form
Srinivasan Standards Track [Page 10]
RFC 1832 XDR: External Data Representation Standard August 1995
type-name identifier;
type-name identifier<>;
The constant m specifies the maximum acceptable element count of
array; if m is not specified, as in the second declaration, it
assumed to be (2**32) - 1.
0 1 2 3
+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
| n | element 0 | element 1 |...|element n-1|
+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
|<-4 bytes->|<--------------n elements------------->|
COUNTED
It is an error to encode a value of n that is greater than
maximum described in the specification
3.14
Structures are declared as follows
struct {
component-declaration-A
component-declaration-B
...
} identifier
The components of the structure are encoded in the order of
declaration in the structure. Each component's size is a multiple
four bytes, though the components may be different sizes
+-------------+-------------+...
| component A | component B |...
+-------------+-------------+...
3.15 Discriminated
A discriminated union is a type composed of a discriminant
by a type selected from a set of prearranged types according to
value of the discriminant. The type of discriminant is either "int",
"unsigned int", or an enumerated type, such as "bool". The
types are called "arms" of the union, and are preceded by the
of the discriminant which implies their encoding.
unions are declared as follows
union switch (discriminant-declaration) {
case discriminant-value-A
Srinivasan Standards Track [Page 11]
RFC 1832 XDR: External Data Representation Standard August 1995
arm-declaration-A
case discriminant-value-B
arm-declaration-B
...
default: default-declaration
} identifier
Each "case" keyword is followed by a legal value of the discriminant
The default arm is optional. If it is not specified, then a
encoding of the union cannot take on unspecified discriminant values
The size of the implied arm is always a multiple of four bytes
The discriminated union is encoded as its discriminant followed
the encoding of the implied arm
0 1 2 3
+---+---+---+---+---+---+---+---+
| discriminant | implied arm | DISCRIMINATED
+---+---+---+---+---+---+---+---+
|<---4 bytes--->|
3.16
An XDR void is a 0-byte quantity. Voids are useful for
operations that take no data as input or no data as output. They
also useful in unions, where some arms may contain data and others
not. The declaration is simply as follows
void
Voids are illustrated as follows
++
||
++
--><-- 0
3.17
The data declaration for a constant follows this form
const name-identifier = n
"const" is used to define a symbolic name for a constant; it does
declare any data. The symbolic constant may be used anywhere
regular constant may be used. For example, the following defines
symbolic constant DOZEN, equal to 12.
Srinivasan Standards Track [Page 12]
RFC 1832 XDR: External Data Representation Standard August 1995
const DOZEN = 12;
3.18
"typedef" does not declare any data either, but serves to define
identifiers for declaring data. The syntax is
typedef declaration
The new type name is actually the variable name in the
part of the typedef. For example, the following defines a new
called "eggbox" using an existing type called "egg":
typedef egg eggbox[DOZEN];
Variables declared using the new type name have the same type as
new type name would have in the typedef, if it was considered
variable. For example, the following two declarations are
in declaring the variable "fresheggs":
eggbox fresheggs; egg fresheggs[DOZEN];
When a typedef involves a struct, enum, or union definition, there
another (preferred) syntax that may be used to define the same type
In general, a typedef of the following form
typedef <definition>> identifier
may be converted to the alternative form by removing the "typedef
part and placing the identifier after the "struct", "union",
"enum" keyword, instead of at the end. For example, here are the
ways to define the type "bool":
typedef enum { /* using typedef */
FALSE = 0,
TRUE = 1
} bool
enum bool { /* preferred alternative */
FALSE = 0,
TRUE = 1
};
The reason this syntax is preferred is one does not have to
until the end of a declaration to figure out the name of the
type
Srinivasan Standards Track [Page 13]
RFC 1832 XDR: External Data Representation Standard August 1995
3.19 Optional-
Optional-data is one kind of union that occurs so frequently that
give it a special syntax of its own for declaring it. It is
as follows
type-name *identifier
This is equivalent to the following union
union switch (bool opted) {
case TRUE
type-name element
case FALSE
void
} identifier
It is also equivalent to the following variable-length
declaration, since the boolean "opted" can be interpreted as
length of the array
type-name identifier<1>;
Optional-data is not so interesting in itself, but it is very
for describing recursive data-structures such as linked-lists
trees. For example, the following defines a type "stringlist"
encodes lists of arbitrary length strings
struct *stringlist {
string item<>;
stringlist next
};
It could have been equivalently declared as the following union
union stringlist switch (bool opted) {
case TRUE
struct {
string item<>;
stringlist next
} element
case FALSE
void
};
or as a variable-length array
struct stringlist<1> {
Srinivasan Standards Track [Page 14]
RFC 1832 XDR: External Data Representation Standard August 1995
string item<>;
stringlist next
};
Both of these declarations obscure the intention of the
type, so the optional-data declaration is preferred over both
them. The optional-data type also has a close correlation to
recursive data structures are represented in high-level
such as Pascal or C by use of pointers. In fact, the syntax is
same as that of the C language for pointers
3.20 Areas for Future
The XDR standard lacks representations for bit fields and bitmaps
since the standard is based on bytes. Also missing are packed (
binary-coded) decimals
The intent of the XDR standard was not to describe every kind of
that people have ever sent or will ever want to send from machine
machine. Rather, it only describes the most commonly used data-
of high-level languages such as Pascal or C so that
written in these languages will be able to communicate easily
some medium
One could imagine extensions to XDR that would let it describe
any existing protocol, such as TCP. The minimum necessary for
are support for different block sizes and byte-orders. The
discussed here could then be considered the 4-byte big-endian
of a larger XDR family
4.
(1) Why use a language for describing data? What's wrong
diagrams
There are many advantages in using a data-description language
as XDR versus using diagrams. Languages are more formal
diagrams and lead to less ambiguous descriptions of data.
are also easier to understand and allow one to think of other
instead of the low-level details of bit-encoding. Also, there is
close analogy between the types of XDR and a high-level language
as C or Pascal. This makes the implementation of XDR encoding
decoding modules an easier task. Finally, the language
itself is an ASCII string that can be passed from machine to
to perform on-the-fly data interpretation
Srinivasan Standards Track [Page 15]
RFC 1832 XDR: External Data Representation Standard August 1995
(2) Why is there only one byte-order for an XDR unit
Supporting two byte-orderings requires a higher level protocol
determining in which byte-order the data is encoded. Since XDR
not a protocol, this can't be done. The advantage of this, though
is that data in XDR format can be written to a magnetic tape,
example, and any machine will be able to interpret it, since
higher level protocol is necessary for determining the byte-order
(3) Why is the XDR byte-order big-endian instead of little-endian
Isn't this unfair to little-endian machines such as the VAX(r),
has to convert from one form to the other
Yes, it is unfair, but having only one byte-order means you have
be unfair to somebody. Many architectures, such as the
68000* and IBM 370*, support the big-endian byte-order
(4) Why is the XDR unit four bytes wide
There is a tradeoff in choosing the XDR unit size. Choosing a
size such as two makes the encoded data small, but causes
problems for machines that aren't aligned on these boundaries.
large size such as eight means the data will be aligned on
every machine, but causes the encoded data to grow too big. We
four as a compromise. Four is big enough to support
architectures efficiently, except for rare machines such as
eight-byte aligned Cray*. Four is also small enough to keep
encoded data restricted to a reasonable size
(5) Why must variable-length data be padded with zeros
It is desirable that the same data encode into the same thing on
machines, so that encoded data can be meaningfully compared
checksummed. Forcing the padded bytes to be zero ensures this
(6) Why is there no explicit data-typing
Data-typing has a relatively high cost for what small advantages
may have. One cost is the expansion of data due to the inserted
fields. Another is the added cost of interpreting these type
and acting accordingly. And most protocols already know what
they expect, so data-typing supplies only redundant information
However, one can still get the benefits of data-typing using XDR.
way is to encode two things: first a string which is the XDR
description of the encoded data, and then the encoded data itself
Another way is to assign a value to all the types in XDR, and
define a universal type which takes this value as its
and for each value, describes the corresponding data type
Srinivasan Standards Track [Page 16]
RFC 1832 XDR: External Data Representation Standard August 1995
5. THE XDR LANGUAGE
5.1 Notational
This specification uses an extended Back-Naur Form notation
describing the XDR language. Here is a brief description of
notation
(1) The characters '|', '(', ')', '[', ']', '"', and '*' are special
(2) Terminal symbols are strings of any characters surrounded
double quotes. (3) Non-terminal symbols are strings of non-
characters. (4) Alternative items are separated by a vertical
("|"). (5) Optional items are enclosed in brackets. (6) Items
grouped together by enclosing them in parentheses. (7) A '*'
following an item means 0 or more occurrences of that item
For example, consider the following pattern
"a " "very" (", " "very")* [" cold " "and "] " rainy "
("day" | "night")
An infinite number of strings match this pattern. A few of them are
"a very rainy day
"a very, very rainy day
"a very cold and rainy day
"a very, very, very cold and rainy night
5.2 Lexical
(1) Comments begin with '/*' and terminate with '*/'. (2)
space serves to separate items and is otherwise ignored. (3)
identifier is a letter followed by an optional sequence of letters
digits or underbar ('_'). The case of identifiers is not ignored
(4) A constant is a sequence of one or more decimal digits
optionally preceded by a minus-sign ('-').
Srinivasan Standards Track [Page 17]
RFC 1832 XDR: External Data Representation Standard August 1995
5.3 Syntax
declaration
type-specifier
| type-specifier identifier "[" value "]"
| type-specifier identifier "<" [ value ] ">"
| "opaque" identifier "[" value "]"
| "opaque" identifier "<" [ value ] ">"
| "string" identifier "<" [ value ] ">"
| type-specifier "*"
| "void
value
|
type-specifier
[ "unsigned" ] "int
| [ "unsigned" ] "hyper
| "float
| "double
| "quadruple
| "bool
| enum-type-
| struct-type-
| union-type-
|
enum-type-spec
"enum" enum-
enum-body
"{"
( identifier "=" value )
( "," identifier "=" value )*
"}"
struct-type-spec
"struct" struct-
struct-body
"{"
( declaration ";" )
( declaration ";" )*
"}"
union-type-spec
"union" union-
Srinivasan Standards Track [Page 18]
RFC 1832 XDR: External Data Representation Standard August 1995
union-body
"switch" "(" declaration ")" "{"
( "case" value ":" declaration ";" )
( "case" value ":" declaration ";" )*
[ "default" ":" declaration ";" ]
"}"
constant-def
"const" identifier "=" constant ";"
type-def
"typedef" declaration ";"
| "enum" identifier enum-body ";"
| "struct" identifier struct-body ";"
| "union" identifier union-body ";"
definition
type-
| constant-
specification
definition *
5.4 Syntax
(1) The following are keywords and cannot be used as identifiers
"bool", "case", "const", "default", "double", "quadruple", "enum",
"float", "hyper", "opaque", "string", "struct", "switch", "typedef",
"union", "unsigned" and "void".
(2) Only unsigned constants may be used as size specifications
arrays. If an identifier is used, it must have been
previously as an unsigned constant in a "const" definition
(3) Constant and type identifiers within the scope of a
are in the same name space and must be declared uniquely within
scope
(4) Similarly, variable names must be unique within the scope
struct and union declarations. Nested struct and union
create new scopes
(5) The discriminant of a union must be of a type that evaluates
an integer. That is, "int", "unsigned int", "bool", an
type or any typedefed type that evaluates to one of these is legal
Also, the case values must be one of the legal values of
discriminant. Finally, a case value may not be specified more
once within the scope of a union declaration
Srinivasan Standards Track [Page 19]
RFC 1832 XDR: External Data Representation Standard August 1995
6. AN EXAMPLE OF AN XDR DATA
Here is a short XDR data description of a thing called a "file",
which might be used to transfer files from one machine to another
const MAXUSERNAME = 32; /* max length of a user name */
const MAXFILELEN = 65535; /* max length of a file */
const MAXNAMELEN = 255; /* max length of a file name */
/*
* Types of files
*/
enum filekind {
TEXT = 0, /* ascii data */
DATA = 1, /* raw data */
EXEC = 2 /* executable */
};
/*
* File information, per kind of file
*/
union filetype switch (filekind kind) {
case TEXT
void; /* no extra information */
case DATA
string creator; /* data creator */
case EXEC
string interpretor; /* program interpretor */
};
/*
* A complete file
*/
struct file {
string filename; /* name of file */
filetype type; /* info about file */
string owner; /* owner of file */
opaque data; /* file data */
};
Srinivasan Standards Track [Page 20]
RFC 1832 XDR: External Data Representation Standard August 1995
Suppose now that there is a user named "john" who wants to store
lisp program "sillyprog" that contains just the data "(quit)".
file would be encoded as follows
OFFSET HEX BYTES ASCII
------ --------- ----- --------
0 00 00 00 09 .... -- length of filename = 9
4 73 69 6c 6c sill -- filename
8 79 70 72 6f ypro -- ... and more characters ...
12 67 00 00 00 g... -- ... and 3 zero-bytes of
16 00 00 00 02 .... -- filekind is EXEC = 2
20 00 00 00 04 .... -- length of interpretor = 4
24 6c 69 73 70 lisp -- interpretor
28 00 00 00 04 .... -- length of owner = 4
32 6a 6f 68 6e john -- owner
36 00 00 00 06 .... -- length of file data = 6
40 28 71 75 69 (qui -- file data bytes ...
44 74 29 00 00 t).. -- ... and 2 zero-bytes of
7. TRADEMARKS AND
SUN WORKSTATION Sun Microsystems, Inc
VAX Digital Equipment
IBM-PC International Business Machines
Cray Cray
NFS Sun Microsystems, Inc
Ethernet Xerox Corporation
Motorola 68000 Motorola, Inc
IBM 370 International Business Machines
Srinivasan Standards Track [Page 21]
RFC 1832 XDR: External Data Representation Standard August 1995
APPENDIX A: ANSI/IEEE Standard 754-1985
The definition of NaNs, signed zero and infinity, and
numbers from [3] is reproduced here for convenience. The
for quadruple-precision floating point numbers are analogs of
for single and double-precision floating point numbers, and
defined in [3].
In the following, 'S' stands for the sign bit, 'E' for the exponent
and 'F' for the fractional part. The symbol 'u' stands for
undefined bit (0 or 1).
For single-precision floating point numbers
Type S (1 bit) E (8 bits) F (23 bits
---- --------- ---------- -----------
signalling NaN u 255 (max) .0uuuuu---
(with at
one 1 bit
quiet NaN u 255 (max) .1uuuuu---
negative infinity 1 255 (max) .000000---0
positive infinity 0 255 (max) .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
For double-precision floating point numbers
Type S (1 bit) E (11 bits) F (52 bits
---- --------- ----------- -----------
signalling NaN u 2047 (max) .0uuuuu---
(with at
one 1 bit
quiet NaN u 2047 (max) .1uuuuu---
negative infinity 1 2047 (max) .000000---0
positive infinity 0 2047 (max) .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
Srinivasan Standards Track [Page 22]
RFC 1832 XDR: External Data Representation Standard August 1995
For quadruple-precision floating point numbers
Type S (1 bit) E (15 bits) F (112 bits
---- --------- ----------- ------------
signalling NaN u 32767 (max) .0uuuuu---
(with at
one 1 bit
quiet NaN u 32767 (max) .1uuuuu---
negative infinity 1 32767 (max) .000000---0
positive infinity 0 32767 (max) .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
Subnormal numbers are represented as follows
Precision Exponent
--------- -------- -----
Single 0 (-1)**S * 2**(-126) * 0.
Double 0 (-1)**S * 2**(-1022) * 0.
Quadruple 0 (-1)**S * 2**(-16382) * 0.
Srinivasan Standards Track [Page 23]
RFC 1832 XDR: External Data Representation Standard August 1995
APPENDIX B:
[1] Brian W. Kernighan & Dennis M. Ritchie, "The C
Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
[2] Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE Computer
October 1981.
[3] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/
Standard 754-1985, Institute of Electrical and
Engineers, August 1985.
[4] "Courier: The Remote Procedure Call Protocol",
Corporation, XSIS 038112, December 1981.
[5] "The SPARC Architecture Manual: Version 8", Prentice Hall
ISBN 0-13-825001-4.
[6] "HP Precision Architecture Handbook", June 1987, 5954-9906.
[7] Srinivasan, R., "Remote Procedure Call Protocol Version 2",
RFC 1831, Sun Microsystems, Inc., August 1995.
Security
Security issues are not discussed in this memo
Author's
Raj
Sun Microsystems, Inc
ONC
2550 Garcia
M/S MTV-5-40
Mountain View, CA 94043
Phone: 415-336-2478
Fax: 415-336-6015
EMail: raj@eng.sun.
Srinivasan Standards Track [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
