rfc1832.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,348 行 · 第 1/4 页


RFC 1832       XDR: External Data Representation Standard    August 1995


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

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

         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.





Srinivasan                  Standards Track                    [Page 13]

RFC 1832       XDR: External Data Representation Standard    August 1995


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

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






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 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
   be unfair to somebody.  Many architectures, such as the Motorola
   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.



Srinivasan                  Standards Track                    [Page 16]

RFC 1832       XDR: External Data Representation Standard    August 1995


5. THE XDR LANGUAGE SPECIFICATION

5.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:

   (1) The characters '|', '(', ')', '[', ']', '"', and '*' are special.
   (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
   ("|").  (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:

         "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 Notes

   (1) Comments begin with '/*' and terminate with '*/'.  (2) White
   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 ('-').















Srinivasan                  Standards Track                    [Page 17]

RFC 1832       XDR: External Data Representation Standard    August 1995


5.3 Syntax Information

      declaration:
           type-specifier identifier
         | type-specifier identifier "[" value "]"
         | type-specifier identifier "<" [ value ] ">"
         | "opaque" identifier "[" value "]"
         | "opaque" identifier "<" [ value ] ">"
         | "string" identifier "<" [ value ] ">"
         | type-specifier "*" identifier
         | "void"

      value:
           constant
         | identifier

      type-specifier:
           [ "unsigned" ] "int"
         | [ "unsigned" ] "hyper"
         | "float"
         | "double"
         | "quadruple"
         | "bool"
         | enum-type-spec
         | struct-type-spec
         | union-type-spec
         | identifier

      enum-type-spec:
         "enum" enum-body

      enum-body:
         "{"
            ( identifier "=" value )
            ( "," identifier "=" value )*
         "}"

      struct-type-spec:
         "struct" struct-body

      struct-body:
         "{"
            ( declaration ";" )
            ( declaration ";" )*
         "}"

      union-type-spec:
         "union" union-body



Srinivasan                  Standards Track                    [Page 18]