ISO/IEC 14496-34:2025
(Main)Information technology — Coding of audio-visual objects — Part 34: Syntactic description language
Information technology — Coding of audio-visual objects — Part 34: Syntactic description language
This document specifies a syntactic description language for describing the structure of binary data. It covers the representation of an SDL specification in plain text, the syntax of the SDL and the semantic rules of the SDL. In scenarios where the usage or interpretation of the SDL are ambiguous or undefined, this document attempts to specify whether such a scenario is considered an invalid SDL specification or will result in undefined behaviour. NOTE While the SDL borrows from and contains some aspects of a general-purpose programming language, it is not intended, nor is it suitable, to be used for such a purpose. This is reflected in the fact that many concepts related to general-purpose programming languages are not addressed in this document. Examples of concepts considered irrelevant to the SDL and therefore not addressed in this document include storage of an SDL specification in a file, compilation, execution, input/output, execution environment and machine architecture.
Technologies de l'information — Codage des objets audiovisuels — Partie 34: Langage de description syntaxique
General Information
Standards Content (Sample)
International
Standard
ISO/IEC 14496-34
First edition
Information technology — Coding of
2025-05
audio-visual objects —
Part 34:
Syntactic description language
Technologies de l'information — Codage des objets
audiovisuels —
Partie 34: Langage de description syntaxique
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Notation . 3
4.1 General .3
4.2 Rule formatting .3
4.3 Rule tokens . .3
4.4 Bitstream examples .3
5 Language concepts and lexical elements . 4
5.1 Character set .4
5.2 Whitespace .5
5.3 Case sensitivity .5
5.4 Comments .5
5.5 Identifiers .5
5.6 Punctuators .6
5.7 Keywords.6
5.8 Operators .7
5.8.1 List of operators .7
5.8.2 Operator precedence and associativity .8
5.8.3 Specific operator behaviour .8
5.9 Expressions and evaluation .9
5.10 Statements .9
5.11 Built-in operators .10
5.12 Numbers . 12
5.12.1 Endianness . . 12
5.12.2 Representation of numbers . 12
5.12.3 Number limits . 12
5.12.4 Value coercion . 12
5.13 Logic values . 13
5.14 Binary literal values . 13
5.15 Hexadecimal literal values .14
5.16 Multiple character literal values .14
5.17 Integer, decimal and floating-point literal values . 15
5.18 String literal values .16
5.19 Scope . .17
5.19.1 General .17
5.19.2 Parsed variable scope .18
5.19.3 Computed variable scope .18
5.20 SDL specification limits .19
6 Elementary data types . 19
6.1 General .19
6.2 Constant-length direct representation bit fields . 20
6.2.1 Alignment . 20
6.2.2 Type . 20
6.2.3 Length .21
6.2.4 Value .21
6.2.5 Constants .21
6.2.6 Look-ahead . 22
6.2.7 Legacy . 22
6.2.8 Reserved . 23
6.3 Variable length direct representation bit fields . 23
© ISO/IEC 2025 – All rights reserved
iii
6.4 Constant-length indirect representation bit fields .24
6.5 Variable length indirect representation bit fields . 26
6.6 Variable length strings .27
6.7 String value . 28
7 Composite data types .28
7.1 Classes . 28
7.2 Base and derived classes . 29
7.3 Abstract classes . 30
7.4 Polymorphism in class declaration .31
7.4.1 General .31
7.4.2 Polymorphism for abstract classes . 33
7.5 Expandable classes . 33
7.6 Parameter types . 35
7.7 Arrays . 39
7.7.1 General . 39
7.7.2 Alignment . 40
7.8 Multi-dimensional arrays . 40
7.9 Partial arrays .41
7.10 Implicit arrays .43
8 Computed variables .44
8.1 General . 44
8.2 Elementary data types . 44
8.2.1 Value .45
8.3 Arrays .45
8.4 Multi-dimensional arrays .45
9 Syntactic flow control .46
9.1 General . 46
9.2 Conditionals . 46
9.3 Loops . 49
Annex A (informative) SDL user guide .53
Bibliography .57
© ISO/IEC 2025 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee JTC 1, Information technology, Subcommittee
SC 29, Coding of audio, picture, multimedia and hypermedia information.
A list of all parts in the ISO 14496 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
© ISO/IEC 2025 – All rights reserved
v
Introduction
This document describes the mechanism with which bitstream syntax is documented in several standard
parts such as in ISO/IEC 14496 or ISO/IEC 23000. This mechanism is called the Syntactic Description
Language (SDL) and is documented here in the form of syntactic and semantic rules.
The SDL builds on concepts defined in the C-like syntax used in ISO/IEC 11172-1 and ISO/IEC 13818-1 to
define an extensible framework for describing bitstreams. This framework is inspired by class typing system
concepts from the C++ and Java programming languages. SDL specialises this class typing system concept by
providing facilities for defining bitstream-level quantities, and how they should be parsed.
The aim of this document is to elevate the SDL syntax which has been used for over 20 years to specify
encoded bitstreams as a standalone part. The SDL syntax was initially defined in a previous edition of
ISO/IEC 14496-1 and this document is largely based on that original syntax.
Lexical elements of the SDL are described first, followed by elementary and composite type constructs
to specify bitstreams. Finally, support for general purpose computation and syntactic control flow are
addressed. Example SDL specification fragments and corresponding bitstreams are provided to clarify
various concepts.
© ISO/IEC 2025 – All rights reserved
vi
International Standard ISO/IEC 14496-34:2025(en)
Information technology — Coding of audio-visual objects —
Part 34:
Syntactic description language
1 Scope
This document specifies a syntactic description language for describing the structure of binary data. It
covers the representation of an SDL specification in plain text, the syntax of the SDL and the semantic rules
of the SDL.
In scenarios where the usage or interpretation of the SDL are ambiguous or undefined, this document
attempts to specify whether such a scenario is considered an invalid SDL specification or will result in
undefined behaviour.
NOTE While the SDL borrows from and contains some aspects of a general-purpose programming language, it is
not intended, nor is it suitable, to be used for such a purpose. This is reflected in the fact that many concepts related
to general-purpose programming languages are not addressed in this document. Examples of concepts considered
irrelevant to the SDL and therefore not addressed in this document include storage of an SDL specification in a file,
compilation, execution, input/output, execution environment and machine architecture.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 10646, Information technology — Universal coded character set (UCS)
IETF RFC 4648, The Base16, Base32, and Base64 Data Encodings
IEEE Std 754-2019, IEEE Standard for Floating-Point Arithmetic
3 Terms and definitions
For the purposes of this document, the following terms, abbreviations and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
fixed length code
FLC
constant-length direct representation bit fields
3.2
syntactic description language
SDL
language defined by this document that allows the description of a bitstream’s syntax
© ISO/IEC 2025 – All rights reserved
3.3
composite type
variable type which consists of an aggregated structure of one or more elements
EXAMPLE Arrays, classes and maps.
3.4
computed variable
variable whose value is only stored in the parsing context (3.10)
3.5
declaration
sequential unit of tokens used to define the ‘shape’ of a variable value without causing data to be consumed
from a bitstream or stored in the parsing context (3.10)
EXAMPLE Class and map declarations.
3.6
definition
sequential unit of tokens used to create a parsed or computed variable (3.4) and its value, potentially causing
data to be consumed from a bitstream or stored in the parsing context (3.10)
EXAMPLE A parsed class variable definition or a computed integer variable definition.
3.7
elementary type
individual numeric value types
EXAMPLE Bits, integers and floats.
3.8
invalid SDL specification
SDL specification (3.11) that is syntactically valid but is nonetheless considered invalid due to either semantic
rules or the fact that such an SDL specification (3.11) would be impossible to interpret or process
3.9
parsed variable
variable whose value is initially stored in a bitstream and once parsed the value is also stored in the parsing
context (3.10)
3.10
parsing context
abstract concept of a volatile storage area for variable values
Note 1 to entry: A computer program implementation would use computer memory for this and may choose to impose
constraints such as storage size.
3.11
SDL specification
formal description of a binary bitstream using the SDL (3.2)
3.12
universal coded character set
UCS
standard set of characters defined by ISO/IEC 10646
3.13
undefined behaviour
behaviour resulting in an undefined outcome based on the interpretation or processing of an SDL
specification (3.11)
Note 1 to entry: Certain scenarios in this document are explicitly identified as resulting in undefined behaviour.
© ISO/IEC 2025 – All rights reserved
Note 2 to entry: A computer program implementation or a standard presenting an SDL specification may choose to
define expected behaviour in these scenarios.
3.14
unspecified constraint
constraint or limit on an SDL specification (3.11) which would need to be defined for it to be viably processed
in some manner by a computer program
Note 1 to entry: As the scope of the SDL does not cover such processing, where appropriate such potential constraints
are identified and explicitly left unspecified.
Note 2 to entry: A computer program implementation or a standard containing an SDL specification may choose to
specify such constraints.
4 Notation
4.1 General
The body of this document outlines the concepts, lexical elements, syntax and semantics. Informal grammar
rules are used throughout to introduce the syntax.
4.2 Rule formatting
The following formatting is used when presenting the informal grammar rules.
— Keywords, punctuators and operators are formatted using a bold monospace font, e.g. keyword.
— Constructs referenced across informal grammar rules are formatted using a bold, italic monospace font,
construct.
e.g.
— Rule tokens used to express the informal grammar rules (defined in 4.3) are formatted using non-italic,
non-bold monospace font, e.g. ‘[’ and ‘]’.
— Identifiers and values are formatted using an italic variable width font, e.g. identifier.
4.3 Rule tokens
The following tokens are used in the informal grammar rules.
— An optional element is indicated by surrounding it with ‘[’ and ‘]’e.g. [optional_element].
— Alternative elements are indicated by separating each alternative by ‘|’ e.g. element_1| element_2.
— An unspecified sequence of one or more elements is indicated by ‘…’ e.g. element;….
4.4 Bitstream examples
This document provides encoded bitstream examples demonstrating the behaviour of various SDL
constructs. The bitstream examples are to be read left to right, top to bottom. Line breaks are irrelevant and
are used purely to allow the annotation of the bitstream. Annotations appear after a comment marker ‘//’.
For example, the following indicates the 32-bit value 0xFF11 encoded in a binary bitstream:
EXAMPLE 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 // first two bytes
// blank lines are irrelevant
0 0 0 0 0 0 0 1 // third byte
0 0 0 0 // another 4 bits
0 0 0 1 // last 4 bits
© ISO/IEC 2025 – All rights reserved
Examples always have a starting parse position. If parsing has just started, the example's starting parse
position will be before the first bit in the bitstream. If parsing has already commenced, the example’s
starting parse position will be after the last parsed bit. In both cases the example's starting parse position
is before the first bit that is relevant to the example. To emphasize the fact that the example may be part of a
larger bitstream, examples will always be preceded and succeeded by ‘…’. As an example:
EXAMPLE 2
... // preceding bits not relevant to example
0 0 0 0 // first 4 bits
0 0 0 1 // last 4 bits
... // succeeding bits not relevant to example
Where skipping an indeterminate number of bits to achieve alignment is part of the example it is indicated
as follows:
EXAMPLE 3
...
// aligned(8)
0 0 0 0 // first 4 bits
0 0 0 1 // last 4 bits
...
5 Language concepts and lexical elements
5.1 Character set
The basic character set used to write an SDL specification consists of:
— The 26 uppercase letters of the Latin alphabet:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
— The 26 lowercase letters of the Latin alphabet:
a b c d e f g h i j k l m n o p q r s t u v w x y z
— The 10 decimal digits:
0 1 2 3 4 5 6 7 8 9
— The following 29 graphic characters:
! " # % & ' ( ) * + , - . / : ; < = > ? [ \ ] ^ _ { | } ~
In certain string literal values and comments, an SDL specification may contain UCS characters (as defined
in ISO/IEC 10646) with the exception of the BOM character (0xFEFF), non-printable characters (0x00 to
0x1F inclusive) and characters causing line feeds (0x85, 0x2028, 0x2029). To represent these excluded UCS
characters, a code point escape sequence may be used (discussed in 5.18).
NOTE 1 String literal values are defined in subclause 5.18.
NOTE 2 Comments are defined in subclause 5.4.
In multiple character literal values, an SDL specification may contain characters from the range 0x20 to
0x7E, inclusive, of ISO/IEC 10646.
NOTE Multiple character literal values are defined in subclause 5.16.
The character set and encoding used to store an SDL specification in a file is not specified in this document.
A computer program implementation or a standard containing an SDL specification may choose to specify
such details.
© ISO/IEC 2025 – All rights reserved
5.2 Whitespace
One or more space, tab or carriage return characters constitute a whitespace and serve to demarcate tokens
in an SDL specification. Whitespace is required wherever parsing of tokens in an SDL specification would be
ambiguous. For example, the following are all valid and equivalent:
EXAMPLE 1
int ( 10 ) i = -1 . 3;
int(10)i=-1.3;
int( 10) i= - 1 .3;
For example, the following is invalid as tokenization of unsigned int is not possible:
EXAMPLE 2
unsignedint i; // missing whitespace causing token ambiguity
Indentation using whitespace is used only for assisting in the readability of an SDL specification and has no
effect on its syntactic or semantic meaning.
5.3 Case sensitivity
The SDL is case sensitive.
5.4 Comments
Comments start by // and continue to the end of the current line. A comment may be preceded by any SDL
syntax between the start of the line and the start of the comment. Comment text may contain SDL compatible
UCS characters (as defined in 5.1). If UCS characters outside of the SDL compatible UCS characters are
required, a code point escape sequence may be used (discussed in 5.18). When parsing tokens in an SDL
specification, the comment start characters // and the remainder of the line are ignored.
Rule S.1: Comments
// This is a comment.
5.5 Identifiers
Identifiers may be comprised of a mixture of upper- and lower-case Latin alphabetic characters, digits and
underscore (e.g. ‘_’). An identifier shall include at least one alphabetic character. For example, the following
are all valid identifiers:
EXAMPLE 1
myVar
My_Var
My2ndVar
2D_Region[2]
_2d_region
An identifier shall not match in a case-sensitive way any SDL syntax items such as keywords, binary,
hexadecimal and string literal prefixes. For example, the following identifiers are all invalid:
EXAMPLE 2
u // conflict with UCS literal string prefix
0b // conflict with binary literal value prefix
MyClass map // conflict with keyword "map"
1e2 // conflict with floating point literal value
2_2 // identifier shall contain at least one alphabetic character
An identifier should not match in a case-insensitive way any SDL syntax items such as keywords, binary,
hexadecimal and string literal. For example:
© ISO/IEC 2025 – All rights reserved
Break // valid but not recommended identifier as it may be confused with the keyword break
NOTE It is possible that some automated tools will generate source code written in a diverse range of programming
languages based on SDL specifications. When defining identifiers in an SDL, it is therefore useful to avoid defining
identifiers conflicting with specific rules of certain programming languages, e.g. identifiers starting with digits or
underscores as these identifiers can be illegal or have specific meaning in some programming languages, or identifiers
conflicting with certain programming language keywords, e.g. public.
5.6 Punctuators
The following punctuator tokens are defined in the SDL:
( open parenthesis
) close parenthesis
{ open brace
} close brace
[ open bracket
] close bracket
: colon
; semicolon
, comma
" double quote
' single quote
5.7 Keywords
The following keyword tokens are defined in the SDL:
abstract
aligned
base64string
bit
break
case
class
computed
const
default
do
else
expandable
extends
float
for
if
int
© ISO/IEC 2025 – All rights reserved
legacy
lengthof
map
reserved
switch
unsigned
utf16string
utf8string
utf8list
utfstring
while
5.8 Operators
5.8.1 List of operators
The following arithmetic, logical and language specific operators are defined in the SDL:
.
class member access, e.g. a.b
[]
array element access, e.g. a[b]
lengthof()
parsed bit length, e.g. lengthof(a)
++
postfix increment, e.g. a++
--
postfix decrement, e.g. a--
+
(unary) plus, e.g. +a
-
(unary) negation, e.g. -a
*
multiplication
/
division
%
modulus
+
addition
-
subtraction
<<
bitwise shift left
>>
bitwise shift right
<
relational less than
<=
relational less than or equal
>
relational greater than
>=
relational greater than or equal
==
relational equal
!=
relational not equal
© ISO/IEC 2025 – All rights reserved
&
bitwise AND
|
bitwise OR
&&
logical AND
||
logical OR
=
assignment (discussed further in 5.9)
5.8.2 Operator precedence and associativity
The operators are presented below in order of descending precedence. Operators appearing on an earlier
line have higher precedence. Operators appearing on the same line have equal precedence. In general,
operators with equal precedence have left-to-right associativity. However, some operators have right-to-left
associativity and these are indicated below:
[] .
++ -- +(unary) -(unary) lengthof() (right-to-left associativity)
* / %
+ -
<< >>
< <= > >=
== !=
&
|
&&
||
= (right-to-left associativity)
A pair of matching parentheses (e.g. ‘(‘ and ‘)’) may be used to group operations to apply specific precedence
and associativity which differ from the default. Parentheses may be used to group more than one operator.
Parentheses may be nested. For example:
EXAMPLE 1
7 * 2 - 4 + 2 // equals 12
7 * (2 – (4 + 2)) // equals -28
5.8.3 Specific operator behaviour
The array element access operator (i.e. ‘[]’) shall be used with positive integer values. The behaviour of the
array element access operator when the operand specifies an element index equal to or greater than the size
of the array is not defined by the SDL which can lead to undefined behaviour.
The modulus operator (i.e. ‘%’) shall not be used with float value operands. The sign of the result for the
modulus operator with negative operands is not defined by the SDL which can lead to undefined behaviour.
The result of the modulus operator where the value of the second operand is zero is not defined by the SDL
which can lead to undefined behaviour.
The division operator (i.e. ‘/’) applied to integer values truncates the result meaning any fractional part of
the value is discarded. The direction of truncation for integer division with negative operands is not defined
by the SDL which can lead to undefined behaviour. The value of division where the value of the second
operand is zero is not defined by the SDL which can lead to undefined behaviour.
The left shift operator (i.e. ‘<<’) fills vacated bits with zero.
© ISO/IEC 2025 – All rights reserved
The right shift operator (i.e. ‘>>’) applied to an unsigned int value fills vacated bits with zero. The behaviour
of the right shift operator applied to a signed int value is not defined by the SDL which can lead to undefined
behaviour.
Usage of the equality (i.e. ‘==’) and inequality operators (i.e. ‘<’, ‘<=’, '>’, ‘>=’ and ‘!=’) with operands of differing
types involves number value coercion (discussed in subclause 5.12.4).
5.9 Expressions and evaluation
An expression is a sequence of operators and operands which are evaluated to produce a result which is
either a value or a reference to a variable. The values of the operands are evaluated first before evaluating
the result of the operator.
For the postfix operators (i.e. ‘++’ and ‘--‘), the value of the operand is used in the expression before the
result of the operator is evaluated. For example:
EXAMPLE 1
i = 1;
j = i++; // j now equals 1 and i equals 2
If a postfix operator (i.e. ‘++’ or ‘--‘) appears on the left-hand side of either an assignment or comparison
operator another postfix operator (i.e. either ‘++’ or ‘--‘) shall not appear on the right-hand side of the same
assignment or comparison operator.
The assignment operator (i.e. =) shall only appear once in an expression. For example, the following is invalid:
EXAMPLE 2
foo1 = foo2 = 1; // illegal usage of assignment more than once in an expression
For the assignment operator (i.e. =), the evaluation order of operands is left to right. For example:
EXAMPLE 3
i = 0;
a[i] = i++; // i is used as an index in the array before it is incremented
// note that i is used as the right-hand value before the postfix increment
// therefore after this expression: a[0] == 0 and i == 1.
For the logical operators (i.e. && and ||), the evaluation order of operands is left-to-right and evaluation will
stop as soon as the logical result value is determined. For example:
EXAMPLE 4
i = 0;
if (i == 0 || i++) { // i++ is not evaluated
j = i; // j will be equal to 0
}
For all binary operators except assignment, coercion is performed implicitly to ensure both operands are of
a common type and the common type is then used for the value of the expression using the operator. For the
assignment operator coercion is performed implicitly to force the right operand value to be the type of the
left operand. Numeric value coercion is discussed in 5.12.4. Logic value coercion is discussed in 5.13.
5.10 Statements
A statement consists of an expression followed by a semicolon. By surrounding a number of statements with
a pair of matching braces ({ and }), the statements are grouped into a block which is itself treated as a single
statement. Such a block is not followed by a semicolon.
Statements are evaluated in sequential order except for scenarios involving syntactic flow control (defined
in Clause 9).
© ISO/IEC 2025 – All rights reserved
5.11 Built-in operators
This lengthof() operator returns the length, in bits, of the parsed variable contained in parentheses. The
length is the number of bits that was most recently used to parse the variable value. A return value of 0
means that no bits were parsed for this variable, e.g. all parsed variable members of a class were contained
in conditional clauses whose conditions were not met. The lengthof() operator shall not be used with a
computed variable.
Rule O.1: lengthof() Operator
lengthof(parsed_variable)
EXAMPLE 1
int(3) foo; // lengthof(foo) == 3
class A { // classes are defined later in this document
int (5) b; // parsed variable
computed int c; // computed variable
}
A a; // lengthof(a) == 5
class Point { // classes are defined later on in this document
computed int x;
computed int y;
}
map points (Point) { // maps are defined later on in this document
0b00, {100, 100},
0b01, {200, 200}
}
Point(points) p; // lengthof(p) == 2
utf8string myString; // if myString == "hello" then lengthof(myString) == 48
// i.e. 5 characters + null termination
computed int i = 5;
computed int j = lengthof(i) // illegal usage of computed variable
computed int k = lengthof(5) // illegal usage of literal value
unsigned int(8)* m; // lookahead is defined later in this document
// lengthof(m) == 8 despite the lookahead
class A {
unsigned int(4) value1;
}
class B extends A { // derived classes are defined later in this document
unsigned int(4) value2;
}
B b;
// lengthof(b) == 8
// lengthof(b.value2) == 4 legal, expression result is a parsed value
// lengthof(b.value2 * 2) illegal, expression result is a computed value
unsigned int(4) a[5]; // arrays are defined later in this document
// lengthof(a) == 20
// lengthof(a[0]) == 4 legal, expression result is a parsed value
// lengthof(a[0] * 2) illegal, expression result is a computed value
class Conditional {
unsigned int(3) foo;
bit(1) bar_flag;
if (bar_flag) { // conditionals are defined later in this document
unsigned int(8) bar;
}
© ISO/IEC 2025 – All rights reserved
}
Conditional c;
// if c.bar_flag == 0, lengthof(c) == 4
// if c.
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...