rfc1014.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,119 行 · 第 1/3 页

   The standard defines a string of n (numbered 0 through n-1) 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+1 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:






SUN Microsystems                                                [Page 7]

RFC 1014              External Data Representation             June 1987


         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
   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 no
   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)---->|
                                                                  STRING

   It is an error to encode a length greater than the maximum described
   in the specification.

3.11 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-1 are encoded by
   individually encoding the elements of the array in their natural
   order, 0 through n-1.  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.

         +---+---+---+---+---+---+---+---+...+---+---+---+---+
         |   element 0   |   element 1   |...|  element n-1  |
         +---+---+---+---+---+---+---+---+...+---+---+---+---+
         |<--------------------n elements------------------->|

                                               FIXED-LENGTH ARRAY





SUN Microsystems                                                [Page 8]

RFC 1014              External Data Representation             June 1987


3.12 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 n-
   1.  The declaration for variable-length arrays follows this form:

         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) - 1.

           0  1  2  3
         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
         |     n     | element 0 | element 1 |...|element n-1|
         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
         |<-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.13 Structure

   Structures are declared as follows:

         struct {
            component-declaration-A;
            component-declaration-B;
            ...
         } 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.

         +-------------+-------------+...
         | component A | component B |...                      STRUCTURE
         +-------------+-------------+...

3.14 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



SUN Microsystems                                                [Page 9]

RFC 1014              External Data Representation             June 1987


   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.

           0   1   2   3
         +---+---+---+---+---+---+---+---+
         |  discriminant |  implied arm  |          DISCRIMINATED UNION
         +---+---+---+---+---+---+---+---+
         |<---4 bytes--->|

3.15 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:

           ++
           ||                                                     VOID
           ++
         --><-- 0 bytes

3.16 Constant

   The data declaration for a constant follows this form:




SUN Microsystems                                               [Page 10]

RFC 1014              External Data Representation             June 1987


         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.17 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];

   When a typedef involves a struct, enum, or union definition, there is
   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":











SUN Microsystems                                               [Page 11]

RFC 1014              External Data Representation             June 1987


         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 wait
   until the end of a declaration to figure out the name of the new
   type.

3.18 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<1>;

   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;
         };





SUN Microsystems                                               [Page 12]

RFC 1014              External Data Representation             June 1987


   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> {
            string item<>;
            stringlist next;
         };

   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.19 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.







SUN Microsystems                                               [Page 13]

RFC 1014              External Data Representation             June 1987


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.