0I/29/2002-page 1
`
`http://'1»/ww.faqs.org/rfcs/rfc1832.html
`
`\ I
`
`U.
`
`Internet RFC/STD/FYI/BCP Archives
`
`
`
`RFC 1832
`
`[IIids=.r|§<ml1|W_11_=;t_‘§.l‘1c3.wlQ9rn.m_:r£|fle.1p;]
`
`Network Working Group
`Request for Comments: 1832
`Category: Standards Track
`
`R. Srinivasan
`Sun Microsystems
`August 1995
`
`XDR: External Data Representation Standard
`
`Status of this Memo
`
`This document specifies an Internet standards track protocol for the
`Internet community, and requests discussion and suggestions for
`improvements.
`Please refer to the current edition of the "Internet
`Official Protocol Standards" (STD 1)
`for the standardization state
`and status of this protocol. Distribution of this memo is unlimited.
`
`ABSTRACT
`
`This document describes the External Data Representation Standard
`(XDR) protocol as it is currently deployed and accepted.
`
`TABLE OF CONTENTS
`
`INTRODUCTION
`1.
`2. BASIC BLOCK SIZE
`3. XDR DATA TYPES
`3.1 lnteqer
`3.2 Unsiqned lnteqer
`3.3 Enumeration
`3.4 Boolean
`3.5 Hyper
`integer and Unsigned Hyper Integer
`3.6 Floa:inq—point
`3.7 Double-precision Floating—point
`3.8 Quadruple—precision Floating-point
`3.9 Fixed-length Opaque Data
`3.10 Variable—length Opaque Data
`3.11 String
`3.12 Fixed-lenqth Array
`3.13 Variable—lenqth Array
`3.14 Structure
`3.15 Discriminated Union
`3.16 Void
`3.17 Constant
`3.28 Typedef
`
`2
`2
`3
`3
`4
`4
`4
`4
`5
`6
`7
`8
`8
`9
`10
`10
`11
`11
`12
`12
`13
`
`lPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 759 of 1442
`
`
`
`

`
`http://www.faqs.org/rfcs/rfc1832.htm1
`
`O1/29/2002--page 2
`
`3.l9 Optional-data
`3.20 Areas for Future Enhancement
`4. DISCUSSION
`5. THE XDR LANGUAGE SPECIFICATION
`5.1 Notational Conventions
`
`5.2 Lexical Notes
`
`5.3 Syntax Information
`5.4 Syntax Notes
`6. AN EXAMPLE OF AN XDR DATA DESCRIPTION
`7. TRADEMARKS AND OWNERS
`APPENDIX A: ANSI/IEEE Standard 754-1985
`APPENDIX B: REFERENCES
`
`Security Considerations
`Author's Address
`
`1.
`
`INTRODUCTION
`
`14
`15
`15
`17
`17
`
`17
`
`18
`19
`20
`21
`22
`24
`
`24
`24
`
`XDR is a standard for the description and encoding of data.
`useful for transferring data between different computer
`architectures, and has been used to communicate data between such
`diverse machines as the SUN WORKSTATION*, VAx*,
`IBM—PC*, and Cray*.
`XDR fits into the ISO presentation layer, and is roughly analogous in
`purpose to X.409,
`ISO Abstract Syntax Notation.
`The major difference
`between these two is that-XDR uses implicit typing, while X.409 uses
`explicit typing.
`
`It is
`
`The language can only
`XDR uses a language to describe data formats.
`be used only to describe data; it is not a programming language.
`This language allows one to describe intricate data formats in a
`concise manner. The alternative of using graphical representations
`(itself an informal
`language) quickly becomes incomprehensible when
`faced with complexity.
`The XDR language itself is similar to the C
`language [1],
`just as Courier
`[4]
`is similar to Mesa. Protocols such
`as ONC RPC (Remote Procedure Call) and the NFS*
`(Network File System)
`use XDR to describe the format of their data.
`
`that bytes (or
`The XDR standard makes the following assumption:
`octets) are portable, where a byte is defined to be 8 bits of data.
`A given hardware device should encode the bytes onto the various
`media in such a way that other hardware devices may decode the bytes
`without
`loss of meaning.
`For example,
`the Ethernet* standard
`suggests that bytes be encoded in "little-endian" style [2], or least
`significant bit first.
`
`2. BASIC BLOCK SIZE
`
`The representation of all items requires a multiple of four bytes (or
`32 bits) of data.
`The bytes are numbered 0 through n-1.
`The bytes
`are read or written to some byte stream such that byte m always
`precedes byte m+l.
`If the n bytes needed to contain the data are not
`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.
`
`we include the familiar graphic box notation for illustration and
`comparison.
`In most illustrations, each box (delimited by_a plus
`sign at the 4 corners and vertical bars and dashes) depicts a byte.
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.760of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 760 of 1442
`
`

`
`http2//www.faqs.org/rfcs/rfc 1 832.htm1
`
`01/29/2002--page 3
`
`Ellipses (...) between boxes show zero or more additional bytes where
`required.
`
`+ —————— —-+ ------ --+...+ ------ —-+ ------ --+...+ ------ —-+
`
`I
`0
`|...|
`0
`|...|byte n—l|
`I byte 1
`I byte 0
`+ ------- -+ ------ —-+
`+ —————— -—+ —————— —-+.
`.+ ------ —-+
`
`BLOCK
`
`|< ————————— ——n bytes ———————— -->|< ---- --r bytes ---- -—>|
`|< ————————— —-n+r
`(where (n+r) mod 4 = 0)> ————————— -—>|
`
`3. XDR DATA TYPES
`
`Each of the sections that follow describes a data type defined in the
`XDR standard,
`shows how it is declared in the language, and includes
`a graphic illustration of its encoding.
`
`For each data type in the language we show a general paradigm
`declaration. Note that angle brackets (< and >) denote
`variablelength sequences of data and square brackets ([ and 1) denote
`fixed—length sequences of data.
`"n",
`"m" and "r" denote integers.
`For the full language specification and more formal definitions of
`terms such as "identifier" and "declaration", refer to section 5:
`"The XDR Language Specification".
`
`For some data types, more specific examples are included.
`extensive example of a data description is in section 6:
`of an XDR Data Description".
`
`A more
`"An Example
`
`3.1 Integer
`
`An XDR signed integer is a 32-bit datum that encodes an integer in
`the range [—2l47483648,2l47483647].
`The integer is represented in
`two's complement notation.
`The most and least significant bytes are
`0 and 3, respectively.
`Integers are declared as follows:
`
`in: identifier;
`
`(LSB)
`(MSB)
`+ —————— —+ ————— —-+ ————— —-+ ————— —-+
`
`I
`Ibyte 3
`Ibyte 2
`|byte 1
`|byte O
`+ —————— —+ ————— —-+ ————— —-+ ————— —-+
`< —————————— ——32 bits —————————— —->
`
`INTEGER
`
`3.2. Unsigned Integer
`
`An XDR unsigned integer is a 32-bit datum that encodes a nonnegative
`integer in the range [0,4294967295].
`It is represented by an
`unsigned binary number whose most and least significant bytes are 0
`and 3, respectively.
`An unsigned integer is declared as follows:
`
`unsigned int identifier;
`
`(LSB)
`(MSB)
`+ —————— —+ ----- —-+ ----- —-+ ----- —-+
`
`1
`lbyte 3
`[byte 2
`lbyte 1
`lbyte 0
`+ —————— —+ ------ —+ ————— —-+ ————— —-+
`< ---------- --32 bits ---------- —->
`
`UNSIGNED INTEGER
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p. 761 of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 761 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc1832.htm1
`
`O1/29/2002--page 4
`
`3.3 Enumeration
`
`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;
`
`the three colors red, yellow, and blue could be
`For example,
`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 that
`have been given assignments in the enum declaration.
`
`3.4 Boolean
`
`Booleans are important enough and occur frequently enough to warrant
`their own explicit type in the standard. Booleans are declared as
`follows:
`
`bool identifier;
`
`This is equivalent
`
`to:
`
`enum { FALSE
`
`0, TRUE = l
`
`}
`
`identifier;
`
`3.5 Hyper Integer and Unsigned Hyper Integer
`
`(8-byte) numbers called hyper
`The standard also defines 64-bit
`integer and unsigned hyper integer. Their representations are the
`obvious extensions of integer and unsigned integer defined above.
`
`The most and
`They are represented in two's complement notation.
`least significant bytes are 0 and 7, respectively. Their
`declarations:
`
`hyper identifier; unsigned hyper identifier;
`
`(LSB)
`,
`(MSB)
`+ —————— -+ —————— —+ ————— -—+ ————— -—+ ----- -—+ ————— -—+ ----- -—+ ————— -—+
`
`|
`Ibyte 7
`Ibyte 6
`Ibyte 5
`Ibyte 4
`Ibyte 3
`Ibyte 2
`Ibyte 1
`Ibyte 0
`+ ————— -—+ ————— -—+ ————— -—+ ————— -—+ ————— -—+ ————— -—+ ----- -—+ ————— -—+
`< —————————————————————————— —-64 bits -------------------------- —->
`HYPER INTEGER
`UNSIGNED HYPER INTEGER
`
`3.6 Floating—point
`
`The standard defines the floating-point data type "float" (32 bits or
`4 bytes).
`The encoding used is the IEEE standard for normalized
`single—precision floating-point numbers [3].
`The following three
`fields describe the single—precision floating-point number:
`
`S: The sign of the number. Values 0 and 1 represent positive and
`negative, respectively. One bit.
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.762of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 762 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc 1832.htrn1
`
`01/29/2002--page 5
`
`8 bits are devoted to this
`E: The exponent of the number, base 2.
`field.
`The exponent is biased by 127.
`
`F: The fractional part of the number's mantissa, base 2.
`are devoted to this field.
`
`23 bits
`
`Therefore,
`
`the floating-point number is described by:
`
`(-l)**S * 2**(E-Bias)
`
`* l.F
`
`It is declared as follows:
`
`float identifier;
`
`+ ————— ——+ ————— ——+ ————— ——+ ————— ——+
`
`I
`[byte 2
`(byte 1
`lbyte 0
`I
`F
`I
`S)
`E
`+ ————— ——+ ————— ——+ ————— ——+ —————— —¢
`
`Ibyte 3
`
`l|<— 8 —>)< ----- --23 bits ———— —->|
`< —————————— ——32 bits —————————— ——>
`
`SINGLE-PRECISION
`FLOATING-POINT NUMBER
`
`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 significant
`
`l, and 9, respectively. Note that
`bit) offsets of S, E, and F are 0,
`these numbers refer to the mathematical positions of the bits, and
`NOT to their actual physical locations (which vary from medium to
`medium).
`
`The IEEE specifications should be consulted concerning the encoding
`for signed zero, signed infinity (overflow), and denormalized numbers
`(underflow)
`[3]. According to IEEE specifications,
`the "NaN"
`(not a
`number)
`is system dependent and should not be interpreted within XDR
`as anything other than "NaN".
`
`3.7 Double—precision Floating—point
`
`The standard defines the encoding for the double-precision floating-
`point data type "double" (64 bits or 8 bytes).
`The encoding used is
`the IEEE standard for normalized double-precision floating—point
`numbers
`[3].
`The standard encodes the following three fields, which
`describe the double—precision floating—point number:
`
`S: The sign of the number. Values 0 and.l represent positive and
`negative, respectively.
`One bit.
`
`[71
`
`11 bits are devoted to
`The exponent of the number, base 2.
`this field.
`The exponent is biased by 1023.
`
`F: The fractional part of the number's mantissa, base 2.
`are devoted to this field.
`
`52 bits
`
`Therefore,
`
`the floating-point number is described by:
`
`(—l)'*S * 2**(E—Bias)
`
`* 1.F
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.763of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 763 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc 1 832.html
`
`01/29/2002——page 6
`
`It is declared as follows:
`
`double identifier;
`
`+ ———— ——+ ———— ——+ ———— ——+ ———— -—+ ———— ——+ ———— ——+ ———— ——+ ———— ——+
`
`Ibyte Otbyte llbyte 2|byte 3lbyte 4|byte Slbyte 6|byte 71
`SI
`E
`I
`F
`I
`+ ———— -—+ ———— ——+ ———— -—+ ———— ——+ ———— ——+ ———— -—+ ———— -—+ ———— -—+
`
`1|<——11——>|< ——————————————— -452 bits ————————————————— —->|
`< ————————————————————— ——64 bits ——————————————————————— -—>
`DOUBLE-PRECISION FLOATING-POINT
`
`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 significant
`bit) offsets of S, E , and F are 0, 1, and 12, respectively. Note
`
`that these numbers refer to the mathematical positions of the bits,
`and NOT to their actual physical locations (which vary from medium to
`medium).
`
`The IEEE specifications should be consulted concerning the encoding
`for signed zero, signed infinity (overflow), and denormalized numbers
`(underflow)
`[3]. According to IEEE specifications,
`the "NaN"
`(not a
`number)
`is system dependent and should not be interpreted within XDR
`as anything other than "NaN".
`
`3.8 Quadruple—precision Floating-point
`
`The standard defines the encoding for the quadruple-precision
`The
`floating-point data type "quadruple" (128 bits or 16 bytes).
`encoding used is designed to be a simple analog of of the encoding
`used for single and double-precision floating-point numbers using one
`form of IEEE double extended precision. The standard encodes the
`following three fields, which describe the quadruple-precision
`floating—point number:
`
`S: The sign of the number. Values 0 and 1 represent positive and
`negative, respectively. One bit.
`
`15 bits are devoted to
`E: The exponent of the number, base 2.
`this field.
`The exponent is biased by 16383.
`
`F: The fractional part of the number's mantissa, base 2.
`are devoted to this field.
`
`112 bits
`
`Therefore,
`
`the floating-point number is described by:
`
`(-l)*‘S ‘ 2**(E-Bias)
`
`*
`
`l.F
`
`It is declared as follows:
`
`quadruple identifier;
`
`+ ———— -—+ ----- -+ ———— ——+ ———— ——+ ———— ——+ ---- --+—...—-+ ---- -—+
`
`lbyte Olbyte llbyte Zlbyte 3lbyte 4Ibyte 5|
`
`...
`
`lbytel5|
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.764of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 764 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc 1 832.htrnl
`
`O1/29/2002--page 7
`
`I
`F
`(
`E
`s(
`+ ————— —+ ———— ——+ ———— ——+ ———— ——+ ---- ——+ ———— ——+—...-—+ ———— ——+
`1(<——-—15————>|< ——————————— --112 bits ———————————————— ——>)
`< ————————————————————— ——l28 bits —————————————————————— ——>
`QUADRUPLE-PRECISION FLOATING-POINT
`
`Just as the most and least significant bytes of a number are 0 and 3,
`the most and least significant bits of a quadruple—precision
`floating-point number are 0 and 127.
`The beginning bit
`(and most
`
`significant bit) offsets of S, E , and F are 0, 1, and 16,
`respectively. Note that these numbers refer to the mathematical
`positions of the bits, and NOT to their actual physical locations
`(which vary from medium to medium).
`
`The encoding for signed zero, signed infinity (overflow), and
`denormalized numbers are analogs of the corresponding encodings for
`single and double-precision floating-point numbers
`[5],
`[6].
`The
`"NaN" encoding as it applies to quadruple-precision floating-point
`numbers is system dependent and should not be interpreted within XDR
`as anything other than "NaN".
`
`3.9 Fixed-length Opaque Data
`
`fixed—length uninterpreted data needs to be passed among
`times,
`At
`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 to
`contain the opaque data.
`If n is not 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 of the opaque object a multiple of four.
`
`...
`l
`0
`+ ——————— —+ ------ -—+...+ —————— ——+ —————— -—+...+ —————— ——+
`
`I
`O
`)...|
`O
`|...|byte n—l)
`I byte 1
`I byte 0
`+ ——————— —+ ——————— —+
`+ ------ ——+ —————— -—+...+ —————— ——+
`
`(< --------- --n bytes -------- -->l< ---- —-r bytes ---- -->|
`)< ————————— ——n+r
`(where (n+r) mod 4 = O) —————————— ——>|
`FIXED-LENGTH OPAQUE
`
`3.10 Variable-length Opaque Data
`
`The standard also provides for variable-length (counted) opaque data,
`defined as a sequence of n (numbered 0 through n—l) arbitrary bytes
`to be the number n encoded as an unsigned integer
`(as described
`below), and followed by the n bytes of the sequence.
`
`Byte m of the sequence always precedes byte m+l of the sequence, and
`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 by
`enough (0 to 3) residual zero bytes, r,
`to make the total byte count
`a multiple of four. Variable-length opaque data is declared in the
`following way:
`
`opaque identifier<m>;
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.765of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 765 of 1442
`
`

`
`htrp://www.faqs.org/rfcs/rfc1832.html
`
`O1/29/2002-~page 8
`
`or
`
`opaque identifier<>;
`
`The constant m denotes an upper bound of the number of bytes that the
`sequence may contain.
`If m is not specified, as in the second
`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 data
`transfer size is 8192 bytes, as follows:
`
`opaque filedata<8l92>;
`
`...
`5
`4
`3
`2
`1
`0
`+—————+-——--+--—-—+————-+-—---+-————+.,.+—————+—-———+...+----—+
`
`I
`0
`I...I
`O
`I
`Ibyte0IbytelI..}I n—l
`length n
`I
`+-————+—-———+—-—-—+———-—+--———+—————+...+—————+—-———+...+—————+
`
`I< ————— ——4 bytes ————— ——>|< ———— ——n bytes ---- —->|<———r bytes——->|
`|<—--—n+r
`(where (n+r) mod 4 = O)---->I
`VARIABLE-LENGTH OPAQUE
`
`It is an error to encode a length greater than the maximum described
`in the specification.
`
`3.ll String
`
`The standard defines a string of n (numbered 0 through n—l) ASCII
`bytes to be the number n encoded as an unsigned integer (as described
`above), and followed by the n bytes of the string. Byte m of the
`_ string always precedes byte m+l of the string, and byte 0 of the
`string always follows the string‘s length.
`If n is not 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 four. Counted
`byte strings are declared as follows:
`
`string object<m>;
`
`or
`
`string object<>;
`
`The constant m denotes an upper bound of the number of bytes that a
`string may contain.
`If m is not specified, as in the second
`
`the maximum length.
`- 1,
`declaration, it is assumed to be (2**32)
`The constant m would normally be found in a protocol specification.
`For example, a filing protocol may state that a file name can be no
`longer than 255 bytes, as follows:
`
`string filename<255>;
`
`...
`5
`4
`3
`2
`1
`0
`+———--+ ---- -+ ———— -+--———+-—---+-——--+,..+-——--+————-+...+—————+
`
`0
`I...I
`0
`I
`|byteOIbytelI...I n—l
`length n
`I
`+ ———— —+ ---- —+————-+---——+———-—+-—-——+...+—--—-+---——+...+----—+
`
`I< ----- --4 bytes ----- —->I< ---- ——n bytes ---- -->|<---r bytes--->l
`I<————n+r
`(where (n+r) mod 4 = 0)————>I
`STRING
`
`It is an error to encode a length greater than the maximum described
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.766of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 766 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc 1 832.html
`
`O1/29/2002--page 9
`
`in the specification.
`
`3.12 Fixed-length Array
`
`Declarations for fixed-length arrays of homogeneous elements are in
`the following form:
`
`type-name identifier[n];
`
`Fixed—length arrays of elements numbered 0 through n—l are encoded by
`individually encoding the elements of the array in their natural
`order,
`0
`through n—l.
`Each element's size is a multiple of four
`bytes. Though all elements are of the same type,
`the elements may
`have different sizes.
`For example,
`in a fixed—length array of
`strings, all elements are of type "string", yet each element will
`vary in its length.
`
`+--—+———+———+-——+———+———+———+—-—+...+—--+---+-——+--—+
`
`I
`element n—l
`|...|
`1
`element
`I
`element 0
`I
`+-——+———+———+——-+s——+---+---+———+...+———+———+--—+———+
`|< —————————————————— ——n elements ————————————————— ——>|
`
`FIXED-LENGTH ARRAY
`
`3.13 Variable-length Array
`
`Counted arrays provide the ability to encode variable—length arrays of
`homogeneous elements.
`The array is encoded as the element count n (an
`unsigned integer)
`followed by the encoding of each of the array's
`elements, starting with element 0 and progressing through element
`The declaration for variable-length arrays follows this form:
`
`n— 1.
`
`type~name identifier<m>;
`
`or
`
`type—name identifier<>;
`
`The constant m specifies the maximum acceptable element count of an
`array;
`if m is not specified, as in the second declaration, it is
`assumed to be (2**32)
`— l.
`
`3
`2
`1
`0
`+-—+——+—-+-—+——+—-+——+-—+——+——+—-+--+...+——+——+——+—-+
`
`|...Ielement n-ll
`1
`! element
`.b| element 0
`n
`I
`+-—+——+—-+——+——+——+—-+——+——+-—+——+--+...+——+—-+——+--+
`
`§<-4 bytes->|< ------------ ——n elements ----------- ——>|
`COUNTED ARRAY
`
`It is an error to encode a value of n that is greater than the
`maximum described in the specification.
`
`3.14 Structure
`
`Structures are declared as follows:
`
`(
`struct
`component-declaration-A;
`component-declaration-B;
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.767of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 767 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc1832.htrn1
`
`01/29/2002--page 10
`
`}
`
`identifier;
`
`The components of the structure are encoded in the order of their
`declaration in the structure.
`Each component's size is a multiple of
`four bytes,
`though the components may be different sizes.
`
`+ ——————————— ——+ ——————————— ——+...
`
`I component A I component B I...
`+ ——————————— ——+ ——————————— ——+...
`
`STRUCTURE
`
`3.15 Discriminated Union
`
`A discriminated union is a type composed of a discriminant followed
`by a type selected from a set of prearranged types according to the
`value of the discriminant.
`The type of discriminant is either "int",
`"unsigned int", or an enumerated type, such as "bool".
`The component
`types are called "arms" of the union, and are preceded by the value
`of the discriminant which implies their encoding. Discriminated
`unions are declared as follows:
`
`union switch (discriminant—declaration)
`case discriminant—value-A:
`
`{
`
`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 valid
`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 by
`the encoding of the implied arm.
`
`3
`2
`1
`0
`+—-—+———+-——+—-—+———+-—-+-——+———+’
`I
`discriminant
`I
`implied arm I
`+———+———+-——+———+———+———+———+—-—+
`
`_
`
`I<———4 bytes--->I
`
`DISCRIMINATED UNION
`
`3.16 Void
`
`An XDR void is a 0-byte quantity. Voids are useful for describing
`operations that take no data as input or no data as output. They are
`also useful in unions, where some arms may contain data and others do
`not.
`The declaration is simply as follows:
`
`void;
`
`Voids are illustrated as follows:
`
`-'r+
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.768of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 768 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc l832.html
`
`01/29/2002--page 1 1
`
`||
`++
`
`--><-— 0 bytes
`
`3.17 Constant
`
`VOID
`
`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 not
`declare any data.
`The symbolic constant may be used anywhere a
`regular constant may be used.
`For example,
`the following defines a
`symbolic constant DOZEN, equal to 12.
`
`const DOZEN = 12;
`
`3.18 Typedef
`
`"typedef" does not declare any data either, but serves to define new
`identifiers for declaring data. The syntax is:
`
`typedef declaration;
`
`The new type name is actually the variable name in the declaration
`part of the typedef.
`For example,
`the following defines a new type
`called "eggbox" using an existing type called "egg":
`
`typedef egg eggbox[DOZEN];
`
`Variables declared using the new type name have the same type as the
`new type name would have in the typedef, if it was considered a
`variable.
`For example,
`the following two declarations are equivalent
`in declaring the variable "fresheggs":
`
`eggbox
`
`fresheggs; egg
`
`fresheggs[DOZEN];
`
`there is
`When a typedef involves a struct, enum, or union definition,
`another
`(preferred) syntax that may be used to define the same type.
`In general, a typedef of the following form:
`
`typedef <<struct, union, or enum definition>> identifier;
`
`may be converted to the alternative form by removing the "typedef"
`part and placing the identifier after the "struct", "union", or
`"enum" keyword,
`instead of at the end.
`For example, here are the two
`ways to define the type "bool":
`
`typedef enum {
`FALSE = O,
`TRUE = l
`} bool;
`
`{
`enum bool
`FALSE = 0,
`TRUE = 1
`
`};
`
`/* using typedef */
`
`/' preferred alternative */
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.769of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 769 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc1832.html
`
`01/29/2002--page 12
`
`The reason this syntax is preferred is one does not have to wait
`until the end of a declaration to figure out
`the name of the new
`type.
`
`3.19 Optional-data
`
`Optional-data is one kind of union that occurs so frequently that we
`give it a special syntax of its own for declaring it.
`It is declared
`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 array
`declaration, since the boolean "opted" can be interpreted as the
`length of the array:
`
`type-name identifier<l>;
`
`Optional-data is not so interesting in itself, but it is very useful
`for describing recursive data-structures such as linked-lists and
`trees.
`For example,
`the following defines a type "stringlist" that
`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;
`
`\1
`
`;
`
`or as a variable-length array:
`
`struct stringlist<l> {
`
`string item<>;
`stringlist next;
`
`};
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.770of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 770 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc 1 832.html
`
`01/29/2002——page 13
`
`Both of these declarations obscure the intention of the stringlist
`type,
`so the optional-data declaration is preferred over both of
`them.
`The optional-data type also has a close correlation to how
`recursive data structures are represented in high-level languages
`such as Pascal or C by use of pointers.
`In fact,
`the syntax is the
`same as that of the C language for pointers.
`
`3.20 Areas for Future Enhancement
`
`The XDR standard lacks representations for bit fields and bitmaps,
`since the standard is based on bytes. Also missing are packed (or
`binary—coded) decimals.
`
`The intent of the XDR standard was not to describe every kind of data
`that people have ever sent or will ever want
`to send from machine to
`machine. Rather, it only describes the most commonly used data—types
`of high—level
`languages such as Pascal or C so that applications
`written in these languages will be able to communicate easily over
`some medium.
`
`One could imagine extensions to XDR that would let it describe almost
`‘any existing protocol,
`such as TCP.
`The minimum necessary for this
`are support for different block sizes and byte-orders.
`The XDR
`discussed here could then be considered the 4-byte big-endian member
`of a larger XDR family.
`
`4. DISCUSSION
`
`(1) Why use a language for describing data? What's wrong with
`diagrams?
`
`There are many advantages in using a data-description language such
`as XDR versus using diagrams.
`Languages are more formal
`than
`diagrams and lead to less ambiguous descriptions of data.
`Languages
`are also easier to understand and allow one to think of other issues
`instead of the low-level details of bit-encoding. Also,
`there is a
`close analogy between the types of XDR and a high—level
`language such
`as C or Pascal. This makes the implementation of XDR encoding and
`decoding modules an easier task. Finally,
`the language specification
`itself is an ASCII string that can be passed from machine to machine
`to perform on—the—fly data interpretation.
`
`(2) Why is there only one byte—order for an XDR unit?
`
`Supporting two byte—orderings requires a higher level protocol for
`determining in which byte—order the data is encoded.
`Since XDR is
`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,
`for
`example, and any machine will be able to interpret it, since no
`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), which
`has to convert
`from one form to the other?
`
`Yes, it is unfair, but having only one byte-order means you have to
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p. 771 of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 771 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc1832.html
`
`O1/29/2002--page 14
`
`such as the Motorola
`be unfair to somebody. Many architectures,
`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 small
`size such as two makes the encoded data small, but causes alignment
`problems for machines that aren't aligned on these boundaries.
`A
`large size such as eight means the data will be aligned on virtually
`every machine, but causes the encoded data to grow too big. We chose
`four as a compromise.
`Four is big enough to support most
`architectures efficiently, except for rare machines such as the
`eight—byte aligned Cray*.
`Four is also small enough to keep the
`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 all
`machines,
`so that encoded data can be meaningfully compared or
`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 it
`may have. One cost is the expansion of data due to the inserted type
`fields. Another
`is the added cost of interpreting these type fields
`and acting accordingly. And most protocols already know what
`type
`they expect,
`so data-typing supplies only redundant information.
`However, one can still get
`the benefits of data-typing using XDR. One
`way is to encode two things: first a string which is the XDR data
`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 then
`define a universal type which takes this value as its discriminant
`and for each value, describes the corresponding data type.
`
`5. THE XDR LANGUAGE SPECIFICATION
`
`U1
`
`.1 Notational Conventions
`
`This specification uses an extended Back-Naur Form notation for
`describing the XDR language. Here is a brief description of the
`notation:
`
`'“‘, and '*' are special.
`'[', ‘]',
`')',
`'(',
`(1) The characters 'l',
`(2) Terminal symbols are strings of any characters surrounded by
`double quotes.
`(3) Non-terminal symbols are strings of non—special
`characters.
`(4) Alternative items are separated by a vertical bar
`("I").
`(5) Optional
`items are enclosed in brackets.
`(6)
`Items are
`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:
`
`II
`(H,
`livery"
`Ila Iv
`(Ivdayn I unightvl)
`
`IIverylI)..-
`
`[ll cold I! "and II]
`
`II rainy ll
`
`An infinite number of strings match this pattern. A few of them are:
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex.1102,p.772of1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 772 of 1442
`
`

`
`http://www.faqs.org/rfcs/rfc1832.html
`
`01/29/2002--page 15
`
`mmmJ
`
`very rainy day"
`very, very rainy day"
`very cold and
`rainy day"
`very, very, very cold and
`
`rainy night"
`
`5.2 Lexical Notes
`
`(2) White
`(1) Comments begin with '/*' and terminate with '*/'.
`space serves to separate items and is otherwise ignored.
`(3) An
`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 ('—').
`
`5.3 Syntax Information
`
`declaration:
`
`">"
`
`type-specifier identifier
`type-specifier identifier "[" value "I"
`I
`type—specifier identifier "<"
`[ value ]
`I
`I "opaque" identifier "I" value "1"
`i "opaque" identifier "<"
`[ value I
`"string" identifier "<"
`[ value I
`type—specifier "*" identifier
`"void"
`
`">"
`">"
`
`I I I
`
`value:
`constant
`identifier
`
`I
`
`type-specifier:
`I "unsigned" ] "int"
`I "unsigned" I "hyper"
`I
`I "float"
`I "double"
`I "quadruple"
`I "bool"
`I enum-type-spec
`I struct-type-spec
`I union—type-spec
`I
`identifier
`
`enum-type—spec:
`"enum