2 .\" Must use -- tbl -- with this one
4 .\" @(#)xdr.rfc.ms 2.2 88/08/05 4.0 RPCSRC
8 .if \\n%=1 .tl ''- % -''
11 .\" prevent excess underlining in nroff
13 .OH 'External Data Representation Standard''Page %'
14 .EH 'Page %''External Data Representation Standard'
17 \&External Data Representation Standard: Protocol Specification
18 .IX "External Data Representation"
20 .IX XDR "protocol specification"
23 \&Status of this Standard
27 Note: This chapter specifies a protocol that Sun Microsystems, Inc., and
28 others are using. It has been designated RFC1014 by the ARPA Network
34 XDR is a standard for the description and encoding of data. It is
35 useful for transferring data between different computer
36 architectures, and has been used to communicate data between such
37 diverse machines as the Sun Workstation, VAX, IBM-PC, and Cray.
38 XDR fits into the ISO presentation layer, and is roughly analogous in
39 purpose to X.409, ISO Abstract Syntax Notation. The major difference
40 between these two is that XDR uses implicit typing, while X.409 uses
43 XDR uses a language to describe data formats. The language can only
44 be used only to describe data; it is not a programming language.
45 This language allows one to describe intricate data formats in a
46 concise manner. The alternative of using graphical representations
47 (itself an informal language) quickly becomes incomprehensible when
48 faced with complexity. The XDR language itself is similar to the C
49 language [1], just as Courier [4] is similar to Mesa. Protocols such
50 as Sun RPC (Remote Procedure Call) and the NFS (Network File System)
51 use XDR to describe the format of their data.
53 The XDR standard makes the following assumption: that bytes (or
54 octets) are portable, where a byte is defined to be 8 bits of data.
55 A given hardware device should encode the bytes onto the various
56 media in such a way that other hardware devices may decode the bytes
57 without loss of meaning. For example, the Ethernet standard
58 suggests that bytes be encoded in "little-endian" style [2], or least
59 significant bit first.
62 .IX XDR "basic block size"
65 The representation of all items requires a multiple of four bytes (or
66 32 bits) of data. The bytes are numbered 0 through n-1. The bytes
67 are read or written to some byte stream such that byte m always
68 precedes byte m+1. If the n bytes needed to contain the data are not
69 a multiple of four, then the n bytes are followed by enough (0 to 3)
70 residual zero bytes, r, to make the total byte count a multiple of 4.
72 We include the familiar graphic box notation for illustration and
73 comparison. In most illustrations, each box (delimited by a plus
74 sign at the 4 corners and vertical bars and dashes) depicts a byte.
75 Ellipses (...) between boxes show zero or more additional bytes where
81 \f(CW+--------+--------+...+--------+--------+...+--------+
82 | byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |
83 +--------+--------+...+--------+--------+...+--------+
84 |<-----------n bytes---------->|<------r bytes------>|
85 |<-----------n+r (where (n+r) mod 4 = 0)>----------->|\fP
93 Each of the sections that follow describes a data type defined in the
94 XDR standard, shows how it is declared in the language, and includes
95 a graphic illustration of its encoding.
97 For each data type in the language we show a general paradigm
98 declaration. Note that angle brackets (< and >) denote
99 variable length sequences of data and square brackets ([ and ]) denote
100 fixed-length sequences of data. "n", "m" and "r" denote integers.
101 For the full language specification and more formal definitions of
102 terms such as "identifier" and "declaration", refer to
103 .I "The XDR Language Specification" ,
106 For some data types, more specific examples are included.
107 A more extensive example of a data description is in
108 .I "An Example of an XDR Data Description"
114 An XDR signed integer is a 32-bit datum that encodes an integer in
115 the range [-2147483648,2147483647]. The integer is represented in
116 two's complement notation. The most and least significant bytes are
117 0 and 3, respectively. Integers are declared as follows:
123 +-------+-------+-------+-------+
124 |byte 0 |byte 1 |byte 2 |byte 3 |
125 +-------+-------+-------+-------+
126 <------------32 bits------------>\fP
130 .IX XDR "unsigned integer"
131 .IX XDR "integer, unsigned"
133 An XDR unsigned integer is a 32-bit datum that encodes a nonnegative
134 integer in the range [0,4294967295]. It is represented by an
135 unsigned binary number whose most and least significant bytes are 0
136 and 3, respectively. An unsigned integer is declared as follows:
139 \fIUnsigned Integer\fP
142 +-------+-------+-------+-------+
143 |byte 0 |byte 1 |byte 2 |byte 3 |
144 +-------+-------+-------+-------+
145 <------------32 bits------------>\fP
151 Enumerations have the same representation as signed integers.
152 Enumerations are handy for describing subsets of the integers.
153 Enumerated data is declared as follows:
156 enum { name-identifier = constant, ... } identifier;
158 For example, the three colors red, yellow, and blue could be
159 described by an enumerated type:
162 enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
164 It is an error to encode as an enum any other integer than those that
165 have been given assignments in the enum declaration.
170 Booleans are important enough and occur frequently enough to warrant
171 their own explicit type in the standard. Booleans are declared as
177 This is equivalent to:
180 enum { FALSE = 0, TRUE = 1 } identifier;
183 \&Hyper Integer and Unsigned Hyper Integer
184 .IX XDR "hyper integer"
185 .IX XDR "integer, hyper"
187 The standard also defines 64-bit (8-byte) numbers called hyper
188 integer and unsigned hyper integer. Their representations are the
189 obvious extensions of integer and unsigned integer defined above.
190 They are represented in two's complement notation. The most and
191 least significant bytes are 0 and 7, respectively. Their
196 \fIUnsigned Hyper Integer\fP
199 +-------+-------+-------+-------+-------+-------+-------+-------+
200 |byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
201 +-------+-------+-------+-------+-------+-------+-------+-------+
202 <----------------------------64 bits---------------------------->\fP
206 .IX XDR "integer, floating point"
207 .IX XDR "floating-point integer"
209 The standard defines the floating-point data type "float" (32 bits or
210 4 bytes). The encoding used is the IEEE standard for normalized
211 single-precision floating-point numbers [3]. The following three
212 fields describe the single-precision floating-point number:
215 The sign of the number. Values 0 and 1 represent positive and
216 negative, respectively. One bit.
218 The exponent of the number, base 2. 8 bits are devoted to this
219 field. The exponent is biased by 127.
221 The fractional part of the number's mantissa, base 2. 23 bits
222 are devoted to this field.
225 Therefore, the floating-point number is described by:
227 (-1)**S * 2**(E-Bias) * 1.F
229 It is declared as follows:
232 \fISingle-Precision Floating-Point\fP
234 \f(CW+-------+-------+-------+-------+
235 |byte 0 |byte 1 |byte 2 |byte 3 |
237 +-------+-------+-------+-------+
238 1|<- 8 ->|<-------23 bits------>|
239 <------------32 bits------------>\fP
241 Just as the most and least significant bytes of a number are 0 and 3,
242 the most and least significant bits of a single-precision floating-
243 point number are 0 and 31. The beginning bit (and most significant
244 bit) offsets of S, E, and F are 0, 1, and 9, respectively. Note that
245 these numbers refer to the mathematical positions of the bits, and
246 NOT to their actual physical locations (which vary from medium to
249 The IEEE specifications should be consulted concerning the encoding
250 for signed zero, signed infinity (overflow), and denormalized numbers
251 (underflow) [3]. According to IEEE specifications, the "NaN" (not a
252 number) is system dependent and should not be used externally.
254 \&Double-precision Floating-point
255 .IX XDR "integer, double-precision floating point"
256 .IX XDR "double-precision floating-point integer"
258 The standard defines the encoding for the double-precision floating-
259 point data type "double" (64 bits or 8 bytes). The encoding used is
260 the IEEE standard for normalized double-precision floating-point
261 numbers [3]. The standard encodes the following three fields, which
262 describe the double-precision floating-point number:
265 The sign of the number. Values 0 and 1 represent positive and
266 negative, respectively. One bit.
268 The exponent of the number, base 2. 11 bits are devoted to this
269 field. The exponent is biased by 1023.
271 The fractional part of the number's mantissa, base 2. 52 bits
272 are devoted to this field.
275 Therefore, the floating-point number is described by:
277 (-1)**S * 2**(E-Bias) * 1.F
279 It is declared as follows:
282 \fIDouble-Precision Floating-Point\fP
284 \f(CW+------+------+------+------+------+------+------+------+
285 |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
287 +------+------+------+------+------+------+------+------+
288 1|<--11-->|<-----------------52 bits------------------->|
289 <-----------------------64 bits------------------------->\fP
291 Just as the most and least significant bytes of a number are 0 and 3,
292 the most and least significant bits of a double-precision floating-
293 point number are 0 and 63. The beginning bit (and most significant
294 bit) offsets of S, E , and F are 0, 1, and 12, respectively. Note
295 that these numbers refer to the mathematical positions of the bits,
296 and NOT to their actual physical locations (which vary from medium to
299 The IEEE specifications should be consulted concerning the encoding
300 for signed zero, signed infinity (overflow), and denormalized numbers
301 (underflow) [3]. According to IEEE specifications, the "NaN" (not a
302 number) is system dependent and should not be used externally.
304 \&Fixed-length Opaque Data
305 .IX XDR "fixed-length opaque data"
306 .IX XDR "opaque data, fixed length"
308 At times, fixed-length uninterpreted data needs to be passed among
309 machines. This data is called "opaque" and is declared as follows:
312 opaque identifier[n];
314 where the constant n is the (static) number of bytes necessary to
315 contain the opaque data. If n is not a multiple of four, then the n
316 bytes are followed by enough (0 to 3) residual zero bytes, r, to make
317 the total byte count of the opaque object a multiple of four.
320 \fIFixed-Length Opaque\fP
323 +--------+--------+...+--------+--------+...+--------+
324 | byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |
325 +--------+--------+...+--------+--------+...+--------+
326 |<-----------n bytes---------->|<------r bytes------>|
327 |<-----------n+r (where (n+r) mod 4 = 0)------------>|\fP
330 \&Variable-length Opaque Data
331 .IX XDR "variable-length opaque data"
332 .IX XDR "opaque data, variable length"
334 The standard also provides for variable-length (counted) opaque data,
335 defined as a sequence of n (numbered 0 through n-1) arbitrary bytes
336 to be the number n encoded as an unsigned integer (as described
337 below), and followed by the n bytes of the sequence.
339 Byte m of the sequence always precedes byte m+1 of the sequence, and
340 byte 0 of the sequence always follows the sequence's length (count).
341 enough (0 to 3) residual zero bytes, r, to make the total byte count
342 a multiple of four. Variable-length opaque data is declared in the
346 opaque identifier<m>;
353 The constant m denotes an upper bound of the number of bytes that the
354 sequence may contain. If m is not specified, as in the second
355 declaration, it is assumed to be (2**32) - 1, the maximum length.
356 The constant m would normally be found in a protocol specification.
357 For example, a filing protocol may state that the maximum data
358 transfer size is 8192 bytes, as follows:
361 opaque filedata<8192>;
363 This can be illustrated as follows:
366 \fIVariable-Length Opaque\fP
369 +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
370 | length n |byte0|byte1|...| n-1 | 0 |...| 0 |
371 +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
372 |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
373 |<----n+r (where (n+r) mod 4 = 0)---->|\fP
376 It is an error to encode a length greater than the maximum
377 described in the specification.
382 The standard defines a string of n (numbered 0 through n-1) ASCII
383 bytes to be the number n encoded as an unsigned integer (as described
384 above), and followed by the n bytes of the string. Byte m of the
385 string always precedes byte m+1 of the string, and byte 0 of the
386 string always follows the string's length. If n is not a multiple of
387 four, then the n bytes are followed by enough (0 to 3) residual zero
388 bytes, r, to make the total byte count a multiple of four. Counted
389 byte strings are declared as follows:
399 The constant m denotes an upper bound of the number of bytes that a
400 string may contain. If m is not specified, as in the second
401 declaration, it is assumed to be (2**32) - 1, the maximum length.
402 The constant m would normally be found in a protocol specification.
403 For example, a filing protocol may state that a file name can be no
404 longer than 255 bytes, as follows:
407 string filename<255>;
409 Which can be illustrated as:
415 +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
416 | length n |byte0|byte1|...| n-1 | 0 |...| 0 |
417 +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
418 |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
419 |<----n+r (where (n+r) mod 4 = 0)---->|\fP
422 It is an error to encode a length greater than the maximum
423 described in the specification.
426 .IX XDR "fixed-length array"
427 .IX XDR "array, fixed length"
429 Declarations for fixed-length arrays of homogeneous elements are in
433 type-name identifier[n];
435 Fixed-length arrays of elements numbered 0 through n-1 are encoded by
436 individually encoding the elements of the array in their natural
437 order, 0 through n-1. Each element's size is a multiple of four
438 bytes. Though all elements are of the same type, the elements may
439 have different sizes. For example, in a fixed-length array of
440 strings, all elements are of type "string", yet each element will
444 \fIFixed-Length Array\fP
446 \f(CW+---+---+---+---+---+---+---+---+...+---+---+---+---+
447 | element 0 | element 1 |...| element n-1 |
448 +---+---+---+---+---+---+---+---+...+---+---+---+---+
449 |<--------------------n elements------------------->|\fP
452 \&Variable-length Array
453 .IX XDR "variable-length array"
454 .IX XDR "array, variable length"
456 Counted arrays provide the ability to encode variable-length arrays
457 of homogeneous elements. The array is encoded as the element count n
458 (an unsigned integer) followed by the encoding of each of the array's
459 elements, starting with element 0 and progressing through element n-
460 1. The declaration for variable-length arrays follows this form:
463 type-name identifier<m>;
468 type-name identifier<>;
470 The constant m specifies the maximum acceptable element count of an
471 array; if m is not specified, as in the second declaration, it is
472 assumed to be (2**32) - 1.
478 +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
479 | n | element 0 | element 1 |...|element n-1|
480 +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
481 |<-4 bytes->|<--------------n elements------------->|\fP
483 It is an error to encode a value of n that is greater than the
484 maximum described in the specification.
489 Structures are declared as follows:
493 component-declaration-A;
494 component-declaration-B;
498 The components of the structure are encoded in the order of their
499 declaration in the structure. Each component's size is a multiple of
500 four bytes, though the components may be different sizes.
505 \f(CW+-------------+-------------+...
506 | component A | component B |...
507 +-------------+-------------+...\fP
510 \&Discriminated Union
511 .IX XDR "discriminated union"
512 .IX XDR union discriminated
514 A discriminated union is a type composed of a discriminant followed
515 by a type selected from a set of prearranged types according to the
516 value of the discriminant. The type of discriminant is either "int",
517 "unsigned int", or an enumerated type, such as "bool". The component
518 types are called "arms" of the union, and are preceded by the value
519 of the discriminant which implies their encoding. Discriminated
520 unions are declared as follows:
523 union switch (discriminant-declaration) {
524 case discriminant-value-A:
526 case discriminant-value-B:
529 default: default-declaration;
532 Each "case" keyword is followed by a legal value of the discriminant.
533 The default arm is optional. If it is not specified, then a valid
534 encoding of the union cannot take on unspecified discriminant values.
535 The size of the implied arm is always a multiple of four bytes.
537 The discriminated union is encoded as its discriminant followed by
538 the encoding of the implied arm.
541 \fIDiscriminated Union\fP
544 +---+---+---+---+---+---+---+---+
545 | discriminant | implied arm |
546 +---+---+---+---+---+---+---+---+
553 An XDR void is a 0-byte quantity. Voids are useful for describing
554 operations that take no data as input or no data as output. They are
555 also useful in unions, where some arms may contain data and others do
556 not. The declaration is simply as follows:
561 Voids are illustrated as follows:
575 The data declaration for a constant follows this form:
578 const name-identifier = n;
580 "const" is used to define a symbolic name for a constant; it does not
581 declare any data. The symbolic constant may be used anywhere a
582 regular constant may be used. For example, the following defines a
583 symbolic constant DOZEN, equal to 12.
592 "typedef" does not declare any data either, but serves to define new
593 identifiers for declaring data. The syntax is:
598 The new type name is actually the variable name in the declaration
599 part of the typedef. For example, the following defines a new type
600 called "eggbox" using an existing type called "egg":
603 typedef egg eggbox[DOZEN];
605 Variables declared using the new type name have the same type as the
606 new type name would have in the typedef, if it was considered a
607 variable. For example, the following two declarations are equivalent
608 in declaring the variable "fresheggs":
612 egg fresheggs[DOZEN];
614 When a typedef involves a struct, enum, or union definition, there is
615 another (preferred) syntax that may be used to define the same type.
616 In general, a typedef of the following form:
619 typedef <<struct, union, or enum definition>> identifier;
621 may be converted to the alternative form by removing the "typedef"
622 part and placing the identifier after the "struct", "union", or
623 "enum" keyword, instead of at the end. For example, here are the two
624 ways to define the type "bool":
627 typedef enum { /* \fIusing typedef\fP */
632 enum bool { /* \fIpreferred alternative\fP */
637 The reason this syntax is preferred is one does not have to wait
638 until the end of a declaration to figure out the name of the new
642 .IX XDR "optional data"
643 .IX XDR "data, optional"
645 Optional-data is one kind of union that occurs so frequently that we
646 give it a special syntax of its own for declaring it. It is declared
650 type-name *identifier;
652 This is equivalent to the following union:
655 union switch (bool opted) {
662 It is also equivalent to the following variable-length array
663 declaration, since the boolean "opted" can be interpreted as the
667 type-name identifier<1>;
669 Optional-data is not so interesting in itself, but it is very useful
670 for describing recursive data-structures such as linked-lists and
671 trees. For example, the following defines a type "stringlist" that
672 encodes lists of arbitrary length strings:
680 It could have been equivalently declared as the following union:
683 union stringlist switch (bool opted) {
693 or as a variable-length array:
696 struct stringlist<1> {
701 Both of these declarations obscure the intention of the stringlist
702 type, so the optional-data declaration is preferred over both of
703 them. The optional-data type also has a close correlation to how
704 recursive data structures are represented in high-level languages
705 such as Pascal or C by use of pointers. In fact, the syntax is the
706 same as that of the C language for pointers.
708 \&Areas for Future Enhancement
711 The XDR standard lacks representations for bit fields and bitmaps,
712 since the standard is based on bytes. Also missing are packed (or
713 binary-coded) decimals.
715 The intent of the XDR standard was not to describe every kind of data
716 that people have ever sent or will ever want to send from machine to
717 machine. Rather, it only describes the most commonly used data-types
718 of high-level languages such as Pascal or C so that applications
719 written in these languages will be able to communicate easily over
722 One could imagine extensions to XDR that would let it describe almost
723 any existing protocol, such as TCP. The minimum necessary for this
724 are support for different block sizes and byte-orders. The XDR
725 discussed here could then be considered the 4-byte big-endian member
726 of a larger XDR family.
731 \&Why a Language for Describing Data?
734 There are many advantages in using a data-description language such
735 as XDR versus using diagrams. Languages are more formal than
736 diagrams and lead to less ambiguous descriptions of data.
737 Languages are also easier to understand and allow one to think of
738 other issues instead of the low-level details of bit-encoding.
739 Also, there is a close analogy between the types of XDR and a
740 high-level language such as C or Pascal. This makes the
741 implementation of XDR encoding and decoding modules an easier task.
742 Finally, the language specification itself is an ASCII string that
743 can be passed from machine to machine to perform on-the-fly data
746 \&Why Only one Byte-Order for an XDR Unit?
749 Supporting two byte-orderings requires a higher level protocol for
750 determining in which byte-order the data is encoded. Since XDR is
751 not a protocol, this can't be done. The advantage of this, though,
752 is that data in XDR format can be written to a magnetic tape, for
753 example, and any machine will be able to interpret it, since no
754 higher level protocol is necessary for determining the byte-order.
756 \&Why does XDR use Big-Endian Byte-Order?
758 Yes, it is unfair, but having only one byte-order means you have to
759 be unfair to somebody. Many architectures, such as the Motorola
760 68000 and IBM 370, support the big-endian byte-order.
762 \&Why is the XDR Unit Four Bytes Wide?
764 There is a tradeoff in choosing the XDR unit size. Choosing a small
765 size such as two makes the encoded data small, but causes alignment
766 problems for machines that aren't aligned on these boundaries. A
767 large size such as eight means the data will be aligned on virtually
768 every machine, but causes the encoded data to grow too big. We chose
769 four as a compromise. Four is big enough to support most
770 architectures efficiently, except for rare machines such as the
771 eight-byte aligned Cray. Four is also small enough to keep the
772 encoded data restricted to a reasonable size.
774 \&Why must Variable-Length Data be Padded with Zeros?
775 .IX XDR "variable-length data"
777 It is desirable that the same data encode into the same thing on all
778 machines, so that encoded data can be meaningfully compared or
779 checksummed. Forcing the padded bytes to be zero ensures this.
781 \&Why is there No Explicit Data-Typing?
783 Data-typing has a relatively high cost for what small advantages it
784 may have. One cost is the expansion of data due to the inserted type
785 fields. Another is the added cost of interpreting these type fields
786 and acting accordingly. And most protocols already know what type
787 they expect, so data-typing supplies only redundant information.
788 However, one can still get the benefits of data-typing using XDR. One
789 way is to encode two things: first a string which is the XDR data
790 description of the encoded data, and then the encoded data itself.
791 Another way is to assign a value to all the types in XDR, and then
792 define a universal type which takes this value as its discriminant
793 and for each value, describes the corresponding data type.
795 \&The XDR Language Specification
799 \&Notational Conventions
800 .IX "XDR language" notation
802 This specification uses an extended Backus-Naur Form notation for
803 describing the XDR language. Here is a brief description of the
817 Terminal symbols are strings of any characters surrounded by
820 Non-terminal symbols are strings of non-special characters.
822 Alternative items are separated by a vertical bar ("\fI|\fP").
824 Optional items are enclosed in brackets.
826 Items are grouped together by enclosing them in parentheses.
830 following an item means 0 or more occurrences of that item.
832 For example, consider the following pattern:
834 "a " "very" (", " " very")* [" cold " "and"] " rainy " ("day" | "night")
837 An infinite number of strings match this pattern. A few of them
841 "a very, very rainy day"
842 "a very cold and rainy day"
843 "a very, very, very cold and rainy night"
848 Comments begin with '/*' and terminate with '*/'.
850 White space serves to separate items and is otherwise ignored.
852 An identifier is a letter followed by an optional sequence of
853 letters, digits or underbar ('_'). The case of identifiers is
856 A constant is a sequence of one or more decimal digits,
857 optionally preceded by a minus-sign ('-').
860 .IX "XDR language" syntax
864 type-specifier identifier
865 | type-specifier identifier "[" value "]"
866 | type-specifier identifier "<" [ value ] ">"
867 | "opaque" identifier "[" value "]"
868 | "opaque" identifier "<" [ value ] ">"
869 | "string" identifier "<" [ value ] ">"
870 | type-specifier "*" identifier
881 | [ "unsigned" ] "hyper"
897 ( identifier "=" value )
898 ( "," identifier "=" value )*
918 "switch" "(" declaration ")" "{"
919 ( "case" value ":" declaration ";" )
920 ( "case" value ":" declaration ";" )*
921 [ "default" ":" declaration ";" ]
925 "const" identifier "=" constant ";"
930 "typedef" declaration ";"
931 | "enum" identifier enum-body ";"
932 | "struct" identifier struct-body ";"
933 | "union" identifier union-body ";"
944 .IX "XDR language" syntax
947 The following are keywords and cannot be used as identifiers:
948 "bool", "case", "const", "default", "double", "enum", "float",
949 "hyper", "opaque", "string", "struct", "switch", "typedef", "union",
950 "unsigned" and "void".
952 Only unsigned constants may be used as size specifications for
953 arrays. If an identifier is used, it must have been declared
954 previously as an unsigned constant in a "const" definition.
956 Constant and type identifiers within the scope of a specification
957 are in the same name space and must be declared uniquely within this
960 Similarly, variable names must be unique within the scope of
961 struct and union declarations. Nested struct and union declarations
964 The discriminant of a union must be of a type that evaluates to
965 an integer. That is, "int", "unsigned int", "bool", an enumerated
966 type or any typedefed type that evaluates to one of these is legal.
967 Also, the case values must be one of the legal values of the
968 discriminant. Finally, a case value may not be specified more than
969 once within the scope of a union declaration.
971 \&An Example of an XDR Data Description
973 Here is a short XDR data description of a thing called a "file",
974 which might be used to transfer files from one machine to another.
979 const MAXUSERNAME = 32; /*\fI max length of a user name \fP*/
980 const MAXFILELEN = 65535; /*\fI max length of a file \fP*/
981 const MAXNAMELEN = 255; /*\fI max length of a file name \fP*/
990 TEXT = 0, /*\fI ascii data \fP*/
991 DATA = 1, /*\fI raw data \fP*/
992 EXEC = 2 /*\fI executable \fP*/
997 * File information, per kind of file:
1001 union filetype switch (filekind kind) {
1003 void; /*\fI no extra information \fP*/
1005 string creator<MAXNAMELEN>; /*\fI data creator \fP*/
1007 string interpretor<MAXNAMELEN>; /*\fI program interpretor \fP*/
1017 string filename<MAXNAMELEN>; /*\fI name of file \fP*/
1018 filetype type; /*\fI info about file \fP*/
1019 string owner<MAXUSERNAME>; /*\fI owner of file \fP*/
1020 opaque data<MAXFILELEN>; /*\fI file data \fP*/
1024 Suppose now that there is a user named "john" who wants to store
1025 his lisp program "sillyprog" that contains just the data "(quit)".
1026 His file would be encoded as follows:
1031 Offset&Hex Bytes&ASCII&Description
1033 0&00 00 00 09&....&Length of filename = 9
1034 4&73 69 6c 6c&sill&Filename characters
1035 8&79 70 72 6f&ypro& ... and more characters ...
1036 12&67 00 00 00&g...& ... and 3 zero-bytes of fill
1037 16&00 00 00 02&....&Filekind is EXEC = 2
1038 20&00 00 00 04&....&Length of interpretor = 4
1039 24&6c 69 73 70&lisp&Interpretor characters
1040 28&00 00 00 04&....&Length of owner = 4
1041 32&6a 6f 68 6e&john&Owner characters
1042 36&00 00 00 06&....&Length of file data = 6
1043 40&28 71 75 69&(qui&File data bytes ...
1044 44&74 29 00 00&t)..& ... and 2 zero-bytes of fill
1049 [1] Brian W. Kernighan & Dennis M. Ritchie, "The C Programming
1050 Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
1052 [2] Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE Computer,
1055 [3] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
1056 Standard 754-1985, Institute of Electrical and Electronics
1057 Engineers, August 1985.
1059 [4] "Courier: The Remote Procedure Call Protocol", XEROX
1060 Corporation, XSIS 038112, December 1981.