TSDL grammar: Fold constant-expression into unary-expression

[ctf.git] / common-trace-format-proposal.txt

diff --git a/common-trace-format-proposal.txt b/common-trace-format-proposal.txt
index dd1996ae498749e27fcbff6f592f41b511afb9ab..ff48de91266ad3029be23003f4f7216e91bf18d1 100644 (file)
--- a/common-trace-format-proposal.txt
+++ b/common-trace-format-proposal.txt
@@ -190,6 +190,9 @@ TSDL meta-data representation:
     byte_order = native OR network OR be OR le; /* default native */
     size = value;                               /* value in bits, no default */
     align = value;                              /* value in bits */
+    /* based used for pretty-printing output, default: decimal. */
+    base = decimal OR dec OR OR d OR i OR u OR 10 OR hexadecimal OR hex OR x OR X OR p OR 16
+           OR octal OR oct OR o OR 8 OR binary OR b OR 2;
   }
 
 Example of type inheritance (creation of a uint32_t named type):
@@ -381,11 +384,11 @@ A CTF variant is a selection between different types. A CTF variant must
 always be defined within the scope of a structure or within fields
 contained within a structure (defined recursively). A "tag" enumeration
 field must appear in either the same lexical scope, prior to the variant
-field (in field declaration order), in an uppermost lexical scope (see
-Section 7.3.1), or in an uppermost dynamic scope (see Section 7.3.2).
-The type selection is indicated by the mapping from the enumeration
-value to the string used as variant type selector. The field to use as
-tag is specified by the "tag_field", specified between "< >" after the
+field (in field declaration order), in an upper lexical scope (see
+Section 7.3.1), or in an upper dynamic scope (see Section 7.3.2). The
+type selection is indicated by the mapping from the enumeration value to
+the string used as variant type selector. The field to use as tag is
+specified by the "tag_field", specified between "< >" after the
 "variant" keyword for unnamed variants, and after "variant name" for
 named variants.
 
@@ -435,7 +438,8 @@ variant example {
 
 struct {
   enum : uint2_t { a, b, c } choice;
-  variant example <choice> v[unsigned int];
+  unsigned int seqlen;
+  variant example <choice> v[seqlen];
 }
 
 Example of an unnamed variant:
@@ -513,20 +517,51 @@ Arrays are always aligned on their element alignment requirement.
 
 4.2.4 Sequences
 
-Sequences are dynamically-sized arrays. They start with an integer that specify
-the length of the sequence, followed by an array of "inner type" elements.
-The length is the number of elements in the sequence.
+Sequences are dynamically-sized arrays. They refer to a a "length"
+unsigned integer field, which must appear in either the same lexical scope,
+prior to the sequence field (in field declaration order), in an upper
+lexical scope (see Section 7.3.1), or in an upper dynamic scope (see
+Section 7.3.2). This length field represents the number of elements in
+the sequence. The sequence per se is an array of "inner type" elements.
 
-TSDL meta-data representation for a named sequence:
+TSDL meta-data representation for a sequence type definition:
 
-typedef elem_type name[length_type];
+struct {
+  unsigned int length_field;
+  typedef elem_type typename[length_field];
+  typename seq_field_name;
+}
+
+A sequence can also be declared as a field type, e.g.:
 
-A nameless sequence can be declared as a field type, e.g.:
+struct {
+  unsigned int length_field;
+  long seq_field_name[length_field];
+}
+
+Multiple sequences can refer to the same length field, and these length
+fields can be in a different upper dynamic scope:
+
+e.g., assuming the stream.event.header defines:
+
+stream {
+  ...
+  id = 1;
+  event.header := struct {
+    uint16_t seq_len;
+  };
+};
 
-long field_name[int];
+event {
+  ...
+  stream_id = 1;
+  fields := struct {
+    long seq_a[stream.event.header.seq_len];
+    char seq_b[stream.event.header.seq_len];
+  };
+};
 
-The length type follows the integer types specifications, and the sequence
-elements follow the "array" specifications.
+The sequence elements follow the "array" specifications.
 
 4.2.5 Strings
 
@@ -1357,11 +1392,8 @@ assignment-operator:
 type-assignment-operator:
        :=
 
-constant-expression:
-       unary-expression
-
 constant-expression-range:
-       constant-expression ... constant-expression
+       unary-expression ... unary-expression
 
 2.2) Declarations:
 
@@ -1405,7 +1437,7 @@ type-specifier:
        ctf-type-specifier
 
 align-attribute:
-       align ( constant-expression )
+       align ( unary-expression )
 
 struct-specifier:
        struct identifier-opt { struct-or-variant-declaration-list-opt } align-attribute-opt
@@ -1431,7 +1463,7 @@ struct-or-variant-declarator-list:
 
 struct-or-variant-declarator:
        declarator
-       declarator-opt : constant-expression
+       declarator-opt : unary-expression
 
 variant-specifier:
        variant identifier-opt variant-tag-opt { struct-or-variant-declaration-list }
@@ -1453,7 +1485,7 @@ enumerator-list:
 
 enumerator:
        enumeration-constant
-       enumeration-constant = constant-expression
+       enumeration-constant = unary-expression
        enumeration-constant = constant-expression-range
 
 type-qualifier:
@@ -1465,8 +1497,7 @@ declarator:
 direct-declarator:
        identifier
        ( declarator )
-       direct-declarator [ type-specifier ]
-       direct-declarator [ constant-expression ]
+       direct-declarator [ unary-expression ]
 
 abstract-declarator:
        pointer-opt direct-abstract-declarator
@@ -1474,8 +1505,7 @@ abstract-declarator:
 direct-abstract-declarator:
        identifier-opt
        ( abstract-declarator )
-       direct-abstract-declarator [ type-specifier ]
-       direct-abstract-declarator [ constant-expression ]
+       direct-abstract-declarator [ unary-expression ]
        direct-abstract-declarator [ ]
 
 pointer: