diff --git a/usrguide/referenceguide/1-about_the_document.adoc b/usrguide/referenceguide/1-about_the_document.adoc
index b010f08f1bd11a8ecee6b8ab1fa7851cbc12f004..152331172f6771f4cb11ad544d56bb961fd44fda 100644
--- a/usrguide/referenceguide/1-about_the_document.adoc
+++ b/usrguide/referenceguide/1-about_the_document.adoc
@@ -7,7 +7,7 @@ The purpose of this document is to provide detailed information on writing compo
== Target Groups
-This document is intended for programmers of TTCN–3 test suites with information in addition to that provided in the <<_13, TITAN User Guide>>. It is recommended that the programmer reads the TITAN User Guide before reading this document.
+This document is intended for programmers of TTCN-3 test suites with information in addition to that provided in the <<_13, TITAN User Guide>>. It is recommended that the programmer reads the TITAN User Guide before reading this document.
== Typographical Conventions
diff --git a/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc b/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc
index d6a05b2cbea93d3537b824e2431919431408bdf4..b151003dc6bd25c233fb922d010d2a7039617f53 100644
--- a/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc
+++ b/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc
@@ -33,7 +33,7 @@ tcov2lcov
. Generate HTML using LCOV’s `genhtml` and the generated `output.info` (see <<converting-code-coverage-data-from-xml-to-html, here>> for more information):
+
[source]
-genhtml –no-branch-coverage –t "Titan Coverage" –legend output.info –o titan_coverage
+genhtml -no-branch-coverage -t "Titan Coverage" -legend output.info -o titan_coverage
. Open `titan_coverage/index.html` in a browser.
@@ -43,7 +43,7 @@ genhtml –no-branch-coverage –t "Titan Coverage" –legend output.info –o t
The `tcov2lcov` tool (binary tool) shipped with Titan and LCOV’s `genhtml` tool (Perl script) are provided to generate human readable HTML from the Titan generated .tcd XML code coverage data files. LCOV’s `genhtml` is not part of the Titan distribution and needs to be installed separately. The basic process is the following:
. Execute `tcov2lcov` to collect and merge all the .tcd files generated during test execution. One .tcd file per component. By default an `output.info` file will be generated in the current working directory, which can be processed directly by LCOV’s `genhtml`. More detailed information about `tcov2lcov` can be found in 10.3.
-. Execute `genhtml` with `output.info` as its input parameter. The recommended parameters are the following:` genhtml –no-branch-coverage -t "Titan Coverage" –legend output.info -o titan_coverage`. For more detailed introduction to `genhtml` and LCOV in general please read their user manuals at http://ltp.sourceforge.net/coverage/lcov.php.
+. Execute `genhtml` with `output.info` as its input parameter. The recommended parameters are the following:` genhtml -no-branch-coverage -t "Titan Coverage" -legend output.info -o titan_coverage`. For more detailed introduction to `genhtml` and LCOV in general please read their user manuals at http://ltp.sourceforge.net/coverage/lcov.php.
[[command-line-syntax-of-tcov2lcov]]
== Command Line Syntax of tcov2lcov
@@ -86,4 +86,4 @@ The Titan compiler implements some optimizations which can affect the accuracy o
External functions are not yet supported and they’re not shown in the statistics.
-The Titan code coverage implementation is based on Titan’s internal location tracking mechanism enabled by the `–L` compiler flag, which must be used together with `-K`. Sometimes it can lead to a little bit confusing or strange code coverage output. E.g. multiple location objects are generated when multiple variable declarations appear on the same line in the TTCN-3 source code. In this case the code coverage output will show that the given line is executed twice. For more complex statements like `for` three location objects are generated etc.
+The Titan code coverage implementation is based on Titan’s internal location tracking mechanism enabled by the `-L` compiler flag, which must be used together with `-K`. Sometimes it can lead to a little bit confusing or strange code coverage output. E.g. multiple location objects are generated when multiple variable declarations appear on the same line in the TTCN-3 source code. In this case the code coverage output will show that the given line is executed twice. For more complex statements like `for` three location objects are generated etc.
diff --git a/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc b/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc
index dadd81c25d55e05946f5f9e938810793e96c33c5..4ac6ffbaa2bfad0a4643e6fbe6e0106bc7ea06c5 100644
--- a/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc
+++ b/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc
@@ -4,7 +4,7 @@
The TTCN-3 debugger is a feature in TITAN, which allows the user to pause (halt) the execution of a TTCN-3 program and print (or in some cases overwrite) information about the current state of the program.
-The compiler option `–n` activates the debugger and augments the generated {cpp} code to store debug information and to allow the addition of breakpoints at runtime. For convenience this option is available for `ttcn3_makefilegen` as well.
+The compiler option `-n` activates the debugger and augments the generated {cpp} code to store debug information and to allow the addition of breakpoints at runtime. For convenience this option is available for `ttcn3_makefilegen` as well.
== Gathered information
@@ -43,10 +43,10 @@ These snapshots contain a time stamp, the function’s name (or the module name
The debugger provides several ways to halt a TTCN-3 program:
-* user breakpoints – breakpoints can be set by the user to any line or function in the TTCN-3 code;
-* automatic breakpoints – certain events can be set to halt the program automatically;
-* stepping – the user can step to the next line of code (when the program is already halted), or to a specific line or function;
-* manual halt – the user can halt the program manually (regardless of which line is currently being executed).
+* user breakpoints - breakpoints can be set by the user to any line or function in the TTCN-3 code;
+* automatic breakpoints - certain events can be set to halt the program automatically;
+* stepping - the user can step to the next line of code (when the program is already halted), or to a specific line or function;
+* manual halt - the user can halt the program manually (regardless of which line is currently being executed).
When the program is halted, no further TTCN-3 code is executed, until the user manually resumes the program’s execution.
@@ -157,13 +157,13 @@ Description: Removes the breakpoint at the specified location (if it exists), or
Examples:
[source]
----
-Example 1 – removing one breakpoint, from module MyModule, line 114:
+Example 1 - removing one breakpoint, from module MyModule, line 114:
drembp MyModule 114
-Example 2 – removing all breakpoints from module MyModule:
+Example 2 - removing all breakpoints from module MyModule:
drembp MyModule all
-Example 3 – removing all breakpoints:
+Example 3 - removing all breakpoints:
drembp all
----
@@ -177,8 +177,8 @@ Description: Activates or deactivates an automatic breakpoint, or changes the ba
Automatic breakpoints are breakpoints triggered by specific events. The first argument indicates which automatic breakpoint to change:
-* *error* – triggered when the component’s verdict is set to `error` by a dynamic test case error (not all dynamic test case errors trigger this breakpoint, only those that actually change the local verdict to `error`);
-* *fail* – triggered when the component’s verdict is set to `fail` (by a `setverdict` operation.
+* *error* - triggered when the component’s verdict is set to `error` by a dynamic test case error (not all dynamic test case errors trigger this breakpoint, only those that actually change the local verdict to `error`);
+* *fail* - triggered when the component’s verdict is set to `fail` (by a `setverdict` operation.
If the automatic breakpoint has a batch file set, then this batch file is automatically executed when the breakpoint is triggered.
@@ -200,7 +200,7 @@ NOTE: In parallel mode output files are created in the host’s working director
[cols="m,",options="header",]
|===
|Meta-character |Substituted with . . .
-|%e |the name of the TTCN–3 executable. The `.exe` suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
+|%e |the name of the TTCN-3 executable. The `.exe` suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
|%h |the name of the computer returned by the `gethostname`(2) system call. This usually does not include the domain name.
|%l |the login name of the current user. If the login name cannot be determined (e.g. the current UNIX user ID has no associated login name) an empty string is returned.
|%n a|* the name of the test component if the PTC has been given a name with the command `create` in the TTCN-3 `create` operation; an empty string otherwise. +
@@ -218,9 +218,9 @@ Default setting: all
Description: Changes the method of storing function call data. The new configuration is specified by the command’s first argument:
-* 'all' – In this case all function calls are stored by the debugger. This option damages the program’s performance the most (specifically its memory consumption), since two long strings are stored every time a function is called and they are not deleted until the program’s execution ends.
-* _buffer size_ – This option sets an upper limit to the amount of function call snapshots stored (equal to `<buffer size>`). The function calls are stored in a ring buffer. If the buffer is full, then storing a new snapshot will cause the oldest stored snapshot to be erased. The buffer size can also be set to zero, in which case no function call data is stored.
-* 'file' – In this case the function call data is sent directly to a file and not stored by the debugger. The file is specified by the second argument.
+* 'all' - In this case all function calls are stored by the debugger. This option damages the program’s performance the most (specifically its memory consumption), since two long strings are stored every time a function is called and they are not deleted until the program’s execution ends.
+* _buffer size_ - This option sets an upper limit to the amount of function call snapshots stored (equal to `<buffer size>`). The function calls are stored in a ring buffer. If the buffer is full, then storing a new snapshot will cause the oldest stored snapshot to be erased. The buffer size can also be set to zero, in which case no function call data is stored.
+* 'file' - In this case the function call data is sent directly to a file and not stored by the debugger. The file is specified by the second argument.
+
The file name may contain special metacharacters, which are substituted dynamically during test execution.
@@ -434,7 +434,7 @@ NOTE: In parallel mode batch files are searched for in the MC’s working direct
== Example
-This section contains an example for some of the debugger’s features. The example contains one TTCN-3 module with one test case, executed in single mode. Two tests are run. In both cases the debugging process is fully automated with the use of batch files. The executable’s –b command line option is used to run the first batch file.
+This section contains an example for some of the debugger’s features. The example contains one TTCN-3 module with one test case, executed in single mode. Two tests are run. In both cases the debugging process is fully automated with the use of batch files. The executable’s -b command line option is used to run the first batch file.
The TTCN-3 module (demo.ttcn):
[source]
diff --git a/usrguide/referenceguide/12-tips_&_troubleshooting.adoc b/usrguide/referenceguide/12-tips_&_troubleshooting.adoc
index d0b025655cb7e7755939f4aa32723e06a36b0b74..bc3763d49da31ac187df8048a80d6163536ad735 100644
--- a/usrguide/referenceguide/12-tips_&_troubleshooting.adoc
+++ b/usrguide/referenceguide/12-tips_&_troubleshooting.adoc
@@ -5,11 +5,11 @@ This chapter deals with various topics, which could not have been assigned to an
== Type Aliasing
-Type aliasing in TTCN–3 means that you can assign an alternative name to an existing type. The syntax is similar to a subtype definition, but the subtype restriction tag (value list or length restriction) is missing.
+Type aliasing in TTCN-3 means that you can assign an alternative name to an existing type. The syntax is similar to a subtype definition, but the subtype restriction tag (value list or length restriction) is missing.
`type MyType MyAlternativeName;`
-The type aliasing is implemented in the test executor, but it translates this TTCN–3 definition to a C `typedef` statement.
+The type aliasing is implemented in the test executor, but it translates this TTCN-3 definition to a C `typedef` statement.
`typedef MyType MyAlternativeName;`
@@ -18,15 +18,15 @@ The limitation of the C typedef is that the {cpp} compiler cannot distinguish be
As a work-around to this problem you can repeat the definition of the original type using the alternative name instead of type aliasing. In this case two differently named, but identical classes will be generated and the polymorphism problem will not occur.
[[reusing-logged-values-or-templates-in-ttcn-3-code]]
-== Reusing Logged Values or Templates in TTCN–3 Code
+== Reusing Logged Values or Templates in TTCN-3 Code
Writing templates can be time-consuming task. To save some time and work, you can use the logs of the messages already sent or received to write templates.
-If you would like to use a logged value in TTCN–3 code, then using the `logformat` utility (see the section 13.3 of the TITAN User Guide [13] about this utility) you have to follow these steps:
+If you would like to use a logged value in TTCN-3 code, then using the `logformat` utility (see the section 13.3 of the TITAN User Guide [13] about this utility) you have to follow these steps:
-. Start a text editor and open the (formatted) log file and the TTCN–3 source file.
+. Start a text editor and open the (formatted) log file and the TTCN-3 source file.
. Select and copy the desired value from the log file.
-. Paste the value at the corresponding position in the TTCN–3 code.
+. Paste the value at the corresponding position in the TTCN-3 code.
. Finally, make the following changes:
+
* The enumerated values are followed by their numerical equivalents within parentheses. Delete them including the parentheses.
@@ -56,10 +56,10 @@ There are minor issues when precompiling TTCN-3 code with a C preprocessor, thes
* There are some predefined macros in the C preprocessor which will be always replaced, do not use any TTCN-3 identifier identical to these. These macros start with double underscore followed by uppercase letters. Some of the most common macros which might be useful:
-** – *FILE* This macro expands to the name of the current input file, in the form of a C string constant.
-** – *LINE* This macro expands to the current input line number, in the form of a decimal integer constant.
-** – *DATE* This macro expands to a string constant that describes the date on which the preprocessor is being run.
-** – *TIME* This macro expands to a string constant that describes the time at which the preprocessor is being run.
+** - *FILE* This macro expands to the name of the current input file, in the form of a C string constant.
+** - *LINE* This macro expands to the current input line number, in the form of a decimal integer constant.
+** - *DATE* This macro expands to a string constant that describes the date on which the preprocessor is being run.
+** - *TIME* This macro expands to a string constant that describes the time at which the preprocessor is being run.
When writing preprocessor directives keep in mind that within the directive the C preprocessor syntax is in use, not the TTCN-3. Operators such as `defined` or || can be used.
diff --git a/usrguide/referenceguide/13-references.adoc b/usrguide/referenceguide/13-references.adoc
index a32c834a31d8309ae191e6b826b6f9b8c6706b99..f6d7ed1c03a7726837971119b452174761d9d85e 100644
--- a/usrguide/referenceguide/13-references.adoc
+++ b/usrguide/referenceguide/13-references.adoc
@@ -4,13 +4,13 @@
* [1] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.01.01_60/es_20187301v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language European Telecommunications Standards Institute ES 201 873-1 Version 4.1.1, July 2009]
[[_2]]
-* [2] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187304/04.01.01_60/es_20187304v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 4: TTCN–3 Operational Semantics European Telecommunications Standards Institute. ES 201 873-4 Version 4.1.1, June 2009]
+* [2] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187304/04.01.01_60/es_20187304v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 4: TTCN-3 Operational Semantics European Telecommunications Standards Institute. ES 201 873-4 Version 4.1.1, June 2009]
[[_3]]
-* [3] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.01.01_60/es_20187307v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCN–3 European Telecommunications Standards Institute. ES 201 873-7 Version 4.1.1, July 2009]
+* [3] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.01.01_60/es_20187307v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCN-3 European Telecommunications Standards Institute. ES 201 873-7 Version 4.1.1, July 2009]
[[_4]]
-* [4] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.01.01_60/es_20187309v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 9: Using XML Schema with TTCN–3 European Telecommunications Standards Institute. ES 201 873-9 Version 4.1.1, June 2009]
+* [4] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.01.01_60/es_20187309v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 9: Using XML Schema with TTCN-3 European Telecommunications Standards Institute. ES 201 873-9 Version 4.1.1, June 2009]
[[_5]]
* [5] link:https://www.etsi.org/deliver/etsi_es/202700_202799/202785/01.05.01_60/es_202785v010501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. TTCN-3 Language Extensions: Behaviour Types European Telecommunications Standards Institute. ES 202 785 Version 1.5.1, Aug 2017]
@@ -31,7 +31,7 @@
* [10] link:https://www.itu.int/rec/T-REC-X.690-200207-S[ITU-T, X.690, Information Technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)International Telecommunication Union, July 2002]
[[_11]]
-* [11] ISO/IEC 10646-1, Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane, Second edition, 200009-15
+* [11] ISO/IEC 10646-1, Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, Second edition, 200009-15
[[_12]]
* [12] link:https://tools.ietf.org/html/rfc3629[RFC3629: UTF-8, a transformation format of ISO 10646]
@@ -73,7 +73,7 @@
* [24] link:https://docs.mongodb.com/manual/reference/mongodb-extended-json/#bson-data-types-and-associated-representations[MongoDB Extended JSON document]
[[_25]]
-* [25] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187311/04.08.01_60/es_20187311v040801p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 11: Using JSON with TTCN–3 European Telecommunications Standards Institute. ES 201 873-11 Version 4.8.1, May 2018]
+* [25] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187311/04.08.01_60/es_20187311v040801p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 11: Using JSON with TTCN-3 European Telecommunications Standards Institute. ES 201 873-11 Version 4.8.1, May 2018]
[[_26]]
* [26] link:https://www.etsi.org/deliver/etsi_es/202700_202799/202782/01.03.01_60/es_202782v010301p.pdf[ETSI ES 202 782 V1.3.1. (2015-06 Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: TTCN-3 Performance and Real Time Testing)]
diff --git a/usrguide/referenceguide/14-abbreviations.adoc b/usrguide/referenceguide/14-abbreviations.adoc
index dfa4c5d9da32a7785fa46f9ffa911ab9980cc611..22aaa0f330c3287c7140500581a3dc31e59109ea 100644
--- a/usrguide/referenceguide/14-abbreviations.adoc
+++ b/usrguide/referenceguide/14-abbreviations.adoc
@@ -10,7 +10,7 @@ ATS:: Abstract Test Suite
BER:: Basic Encoding Rules (of ASN.1)
-BNF:: Backus–Naur Formalism
+BNF:: Backus-Naur Formalism
CER:: Canonical Encoding Rules (of ASN.1)
@@ -88,9 +88,9 @@ TR:: Trouble Report
TTCN:: Testing and Test Control Notation
-TTCN–2:: Tree and Tabular Combined Notation version 2
+TTCN-2:: Tree and Tabular Combined Notation version 2
-TTCN–3:: Tree and Tabular Combined Notation version 3 (formerly)Testing and Test Control Notation (new resolution)
+TTCN-3:: Tree and Tabular Combined Notation version 3 (formerly)Testing and Test Control Notation (new resolution)
UDP:: User Datagram Protocol
diff --git a/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc b/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
index af6bdb00fa7d9a36374aa7369a4318063985456a..ffd63081bb4f80177cb06cbe401f1349124e09ba 100644
--- a/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
+++ b/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
@@ -1,24 +1,24 @@
= TTCN-3 Limitations in this Version
:toc:
-The present Test Executor is an implementation of TTCN–3 Core Language standard (<<13-references.adoc#_1, [1]>>) with support of ASN.1 (<<13-references.adoc#_3, [3]>>). However, the following TTCN–3 language constructs are not supported in the current version of the Test Executor. When applicable, the relevant clause of the standard text (<<13-references.adoc#_1, [1]>>) is given within parentheses after each limitation. The list of ASN.1 related limitations can be found in chapter *4.25*.
+The present Test Executor is an implementation of TTCN-3 Core Language standard (<<13-references.adoc#_1, [1]>>) with support of ASN.1 (<<13-references.adoc#_3, [3]>>). However, the following TTCN-3 language constructs are not supported in the current version of the Test Executor. When applicable, the relevant clause of the standard text (<<13-references.adoc#_1, [1]>>) is given within parentheses after each limitation. The list of ASN.1 related limitations can be found in chapter *4.25*.
* {cpp} code generation for parameterized local templates is not supported.footnote:[The semantic analyzer is able to verify modules with such definitions, but the generated {cpp} code will be incomplete or erroneous.] (5.0, relevant cells of Table 1)
-* Parameterized TTCN–3 `record`, `set` and `union types`. (5.4 in <<13-references.adoc#_1, [1]>>))
-* TTCN–3 sub-typing constraints are checked only at compilation time. In the run-time environment the restricted types are substituted with the corresponding base type and no run-time error is produced if the assigned value violates the subtype constraint.
-* The special TTCN–3 type `anytype` is supported with restrictions. (6.2.6 in <<13-references.adoc#_1, [1]>>)
+* Parameterized TTCN-3 `record`, `set` and `union types`. (5.4 in <<13-references.adoc#_1, [1]>>))
+* TTCN-3 sub-typing constraints are checked only at compilation time. In the run-time environment the restricted types are substituted with the corresponding base type and no run-time error is produced if the assigned value violates the subtype constraint.
+* The special TTCN-3 type `anytype` is supported with restrictions. (6.2.6 in <<13-references.adoc#_1, [1]>>)
* Type compatibility of structured types.footnote:[Type compatibility for structured types is enabled only in the function test run-time due to performance considerations (except record of/set of types for certain element types, see section 4.32.2). In the load test run-time aliased types and sub-types are treated to be equivalent to their unrestricted root types. Different structured types are incompatible to each other. Two array types are compatible if both have the same size and index offset and the element types are compatible according to the rules above.] (6.3 in <<13-references.adoc#_1, [1]>>)
* Two (non-empty) component types are considered to be compatible only if the compatibility relation is explicitly specified by the test suite writer. Details can be found in section 4.21. (6.3.3 and 9.3 in <<13-references.adoc#_1, [1]>>)
-* Selective import statements. All TTCN–3 imports are treated as `import all`.footnote:[Recursive and non-recursive import means exactly the same when importing all definitions from a module.] (8.2.3 and F.2 in <<13-references.adoc#_1, [1]>>)
-* Type `address` must not be an external type specified outside TTCN–3. The special value `null` cannot be assigned to variables of type `address`. (9.6 in <<13-references.adoc#_1, [1]>>)
-* The compiler does not check whether a TTCN–3 function invoked from within a `template`, Boolean guard expression of an alt construct, local variable initializer of an `altstep` or an `interleave` statement has side-effects. The run-time behavior is undefined if a function with side-effects (e.g. communication operations) is called while one of the above statements is being executed. (20 in <<13-references.adoc#_1, [1]>>)
+* Selective import statements. All TTCN-3 imports are treated as `import all`.footnote:[Recursive and non-recursive import means exactly the same when importing all definitions from a module.] (8.2.3 and F.2 in <<13-references.adoc#_1, [1]>>)
+* Type `address` must not be an external type specified outside TTCN-3. The special value `null` cannot be assigned to variables of type `address`. (9.6 in <<13-references.adoc#_1, [1]>>)
+* The compiler does not check whether a TTCN-3 function invoked from within a `template`, Boolean guard expression of an alt construct, local variable initializer of an `altstep` or an `interleave` statement has side-effects. The run-time behavior is undefined if a function with side-effects (e.g. communication operations) is called while one of the above statements is being executed. (20 in <<13-references.adoc#_1, [1]>>)
* The `disconnect` and `unmap` operations cannot refer to multiple connections or mappings. (21.1.2, relevant parts in <<13-references.adoc#_1, [1]>>)
* The `send` and `call` operations cannot be used for multicast or broadcast communication. (22.2.1 and 22.3.1 in <<13-references.adoc#_1, [1]>>)
* Attributes of type definitions cannot be changed when they are being imported. (27.1.2.1 in <<13-references.adoc#_1, [1]>>)
* Template instances cannot be used in the to clause of communication operations. Only values of `component` and `address` types are allowed. (stated only in BNF)
* The additional predefined function `decomp` is not implemented. (D.2 of <<13-references.adoc#_3, [3]>>)
* In `port type` definitions the list of incoming and outgoing message types or signatures must be explicitly specified, the `all` keyword is ignored by the compiler. (G.3 in <<13-references.adoc#_1, [1]>>)
-* The TTCN–3 and ASN.1 modules are identified only by their names. Object identifiers in module headers are ignored. Module object identifiers in `import` statements and references are skipped without any checking, the semantic analyzer uses the module identifier only. (7.2.3 of <<13-references.adoc#_3, [3]>>, 8.1 in <<13-references.adoc#_1, [1]>>)
+* The TTCN-3 and ASN.1 modules are identified only by their names. Object identifiers in module headers are ignored. Module object identifiers in `import` statements and references are skipped without any checking, the semantic analyzer uses the module identifier only. (7.2.3 of <<13-references.adoc#_3, [3]>>, 8.1 in <<13-references.adoc#_1, [1]>>)
* The comparison operators do not work on `objid` values. Only the equality (==) and non-equality (!=) operators are allowed. (7.2.5.2 of <<13-references.adoc#_3, [3]>>, 7.1.3 in <<13-references.adoc#_1, [1]>>)
* Templates can not be used in the parameter of `encvalue` built-in function. (C.38 in <<13-references.adoc#_1, [1]>>)
* The declaration of object identifiers can only point to constant values and integer variables, references to `objid` variables are not supported.
diff --git a/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc b/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc
index f37f9f9063e41ac8ffa68392abe43049217fb4b8..a5eba1d90e8f6c15bc34bb6be92f927a5b492c15 100644
--- a/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc
+++ b/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc
@@ -1,7 +1,7 @@
= Clarifications to the TTCN-3 Standard
:toc:
-The TTCN–3 Core Language standard (<<13-references.adoc#_1, [1]>>) and its Operational Semantics (<<13-references.adoc#_1, [1]>>) give ambiguous description for some language constructs. This section specifies our resolution for these ambiguities that was followed during the implementation of our compiler and run-time environment.
+The TTCN-3 Core Language standard (<<13-references.adoc#_1, [1]>>) and its Operational Semantics (<<13-references.adoc#_1, [1]>>) give ambiguous description for some language constructs. This section specifies our resolution for these ambiguities that was followed during the implementation of our compiler and run-time environment.
== Predefined Function Identifiers
@@ -29,7 +29,7 @@ In the standard, it is not clear that the `VariableList` notation in the `param`
== References between Language Elements
-The TTCN–3 standard does not specify clearly the permitted references between different kinds of language elements. The following table shows our interpretation.
+The TTCN-3 standard does not specify clearly the permitted references between different kinds of language elements. The following table shows our interpretation.
.References between TTCN-3 elements
[cols=",,,,,",options="header",]
@@ -46,16 +46,16 @@ The TTCN–3 standard does not specify clearly the permitted references between
Legend:
-* N Not allowed by the TTCN–3 language.
+* N Not allowed by the TTCN-3 language.
-* Y Allowed and fully supported by the current version of this TTCN–3 tool.
+* Y Allowed and fully supported by the current version of this TTCN-3 tool.
* Y* Allowed and fully supported, but circular reference chains must be avoided.
[NOTE]
====
* The above table implies that the value of all constants and the attributes of all type constructs (type constraints, array sizes, etc.) shall be known at compilation time.
-* ASN.1 value assignments are treated as TTCN–3 constants.
+* ASN.1 value assignments are treated as TTCN-3 constants.
* The value of constants shall refer only to built-in operators or additional predefined functions.
* The body of non-parameterized templates and the default duration of timers shall be known at test startup (load) time when all module parameters are known.
* The actual parameters of templates or the actual duration of timers shall be determined run-time because the actual value of variables may be referred.
@@ -77,22 +77,22 @@ The standard does not specify clearly some of the encoding rules.
== Address Type
-The standard does not specify clearly the status of special TTCN–3 type `address`. Our implementation is based on the rules below.
+The standard does not specify clearly the status of special TTCN-3 type `address`. Our implementation is based on the rules below.
-The test suite writer can assign the name `address` to a regular data type. There can be at most one type named `address` in each TTCN–3 module. It is allowed that different modules of the test suite assign the name `address` to different types.
+The test suite writer can assign the name `address` to a regular data type. There can be at most one type named `address` in each TTCN-3 module. It is allowed that different modules of the test suite assign the name `address` to different types.
-The name `address` cannot be assigned to the following TTCN–3 types:
+The name `address` cannot be assigned to the following TTCN-3 types:
* port types
* component typesfootnote:[If component types were allowed for addressing the compiler would not be able to decide whether a component reference in the to or from clause of a communication operation denotes a test component, which is reachable through a port connection or an address inside the SUT, which is reachable through a port mapping.]
* signatures
-* the built-in type defaultfootnote:[The values of type default (i.e. the TTCN–3 default references) cannot be passed outside the test component by any means.]
+* the built-in type defaultfootnote:[The values of type default (i.e. the TTCN-3 default references) cannot be passed outside the test component by any means.]
-Whenever the word `address` is used as a type, it is assumed to be a reference to the type named `address` in the current module. The type named `address` cannot be imported into another TTCN–3 module, that is, it can be referenced using the name `address` only within its own module. If one wants to use this type in other modules a regular alternate name must be assigned to it with type aliasing.
+Whenever the word `address` is used as a type, it is assumed to be a reference to the type named `address` in the current module. The type named `address` cannot be imported into another TTCN-3 module, that is, it can be referenced using the name `address` only within its own module. If one wants to use this type in other modules a regular alternate name must be assigned to it with type aliasing.
Addressing the SUT in communication operations is allowed only if the `address` type is defined in the same module as the corresponding port type. In addition, the port type must have a special `extension` attribute to support `address` values (See section "Support of address type" in <<13-references.adoc#_16, [16]>> for more details).
-Note that it is possible to use different address types on different ports in the same TTCN–3 module if the respective port types are imported from different modules, but neither address type may be referenced with name `address` by the importing module.
+Note that it is possible to use different address types on different ports in the same TTCN-3 module if the respective port types are imported from different modules, but neither address type may be referenced with name `address` by the importing module.
[[importing-import-statement-from-ttcn-3-modules]]
== Importing import Statement from TTCN-3 Modules
@@ -170,9 +170,9 @@ This isn't the case in the TITAN runtime. Values only have 2 states: _bound_ and
* `record` / `set`: unbound = uninitialized, bound = at least partially initialized, meaning that a `record` / `set` is bound if at least one of its fields is boundfootnote:[The bound state of fields or elements is also determined by using the isbound operation on the field or element.];
* `record of` / `set of`: unbound = uninitialized, bound = at least partially initialized, meaning that the record of is only unbound if it has never received an initial value (even initializing with {} creates a bound `record of` / `set of` value);
* `array`: unbound = uninitialized or partially initialized, bound = fully initialized, meaning that the array is only bound if all of its elements are bound;
-* `unions` can't be partially initialized, so TITAN stores their bound state correctly (although it's still possible to create `union` values, where the selected alternative is unbound, with the legacy command line option `–B`; these values would be considered bound by TITAN).
+* `unions` can't be partially initialized, so TITAN stores their bound state correctly (although it's still possible to create `union` values, where the selected alternative is unbound, with the legacy command line option `-B`; these values would be considered bound by TITAN).
-There is a workaround in TITAN's implementation of `records` / `sets` to allow the copying of partially initialized values (`union` values with unbound selected alternatives can also be copied when the compiler option `–B` is set). In all other cases the user is responsible for making sure the value is usable on the right hand side of an operation. The `isbound` function is usually not enough to ensure, that the value is usable.
+There is a workaround in TITAN's implementation of `records` / `sets` to allow the copying of partially initialized values (`union` values with unbound selected alternatives can also be copied when the compiler option `-B` is set). In all other cases the user is responsible for making sure the value is usable on the right hand side of an operation. The `isbound` function is usually not enough to ensure, that the value is usable.
== Concatenation of templates
diff --git a/usrguide/referenceguide/4-ttcn3_language_extensions.adoc b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
index 5982726f6a2d1e279ced3b87870f1be8f9e45eb5..a02b6ac34a70d7d221fd0b96373def42695686a2 100644
--- a/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
+++ b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
@@ -1,21 +1,21 @@
[[ttcn-3-language-extensions]]
-= TTCN–3 Language Extensions
+= TTCN-3 Language Extensions
:toc:
:table-number: 3
-The Test Executor supports the following non-standard additions to TTCN–3 Core Language in order to improve its usability or provide backward compatibility with older versions.
+The Test Executor supports the following non-standard additions to TTCN-3 Core Language in order to improve its usability or provide backward compatibility with older versions.
== Syntax Extensions
-The compiler does not report an error or warning if the semi-colon is missing at the end of a TTCN–3 definition although the definition does not end with a closing bracket.
+The compiler does not report an error or warning if the semi-colon is missing at the end of a TTCN-3 definition although the definition does not end with a closing bracket.
The statement block is optional after the guard operations of `altsteps`, `alt` and `interleave` constructs and in the response and exception handling part of `call` statements. A missing statement block has the same meaning as an empty statement block. If the statement block is omitted, a terminating semi-colon must be present after the guard statement.
-The standard escape sequences of C/{cpp} programming languages are recognized and accepted in TTCN–3 character string values, that is, in literal values of `charstring` and `universal` `charstring` types, as well as in the arguments of built-in operations `log()` and `action()`.
+The standard escape sequences of C/{cpp} programming languages are recognized and accepted in TTCN-3 character string values, that is, in literal values of `charstring` and `universal` `charstring` types, as well as in the arguments of built-in operations `log()` and `action()`.
-NOTE: As a consequence of the extended escape sequences and in contrast with the TTCN–3 standard, the backslash character itself has to be always duplicated within character string values.
+NOTE: As a consequence of the extended escape sequences and in contrast with the TTCN-3 standard, the backslash character itself has to be always duplicated within character string values.
-The following table summarizes all supported escape sequences of TTCN–3 character string values:
+The following table summarizes all supported escape sequences of TTCN-3 character string values:
.Character string escape sequences
[cols=",,",options="header",]
@@ -35,18 +35,18 @@ The following table summarizes all supported escape sequences of TTCN–3 charac
|Â <newline> |nothing |line continuation
| |NNN |octal notation (NNN is the character code in at most 3 octal digits)
| |NN |hexadecimal notation (NN is the character code in at most 2 hexadecimal digits)
-|"" |34 |quotation mark (standard notation of TTCN–3 )
+|"" |34 |quotation mark (standard notation of TTCN-3 )
|===
NOTE: Only the standardized escape sequences are recognized in matching patterns of character string templates because they have special meaning there. For example, inside string patterns `\n` denotes a set of characters rather than a single character.
-Although the standard requires that characters of TTCN–3 `charstring` values must be between 0 and 127, TITAN allows characters between 0 and 255. The printable representation of characters with code 128 to 255 is undefined.
+Although the standard requires that characters of TTCN-3 `charstring` values must be between 0 and 127, TITAN allows characters between 0 and 255. The printable representation of characters with code 128 to 255 is undefined.
-The compiler implements an ASN.1-like scoping for TTCN–3 enumerated types, which means it allows the re-use of the enumerated values as identifiers of other definitions. The enumerated values are recognized only in contexts where enumerated values are expected; otherwise the identifiers are treated as simple references. However, using identifiers this way may cause misleading error messages and complicated debugging.
+The compiler implements an ASN.1-like scoping for TTCN-3 enumerated types, which means it allows the re-use of the enumerated values as identifiers of other definitions. The enumerated values are recognized only in contexts where enumerated values are expected; otherwise the identifiers are treated as simple references. However, using identifiers this way may cause misleading error messages and complicated debugging.
The compiler allows the local definitions (constants, variables, timers) to be placed in the middle of statement blocks, that is, after other behavior statements. The scope of such definitions extends from the statement following the definition to the end of the statement block. Forward-referencing of local definitions and jumping forward across them using `goto` statements are not allowed.
-The compiler accepts in-line compound values in the operands of TTCN–3 expressions although the BNF of the standard allows only single values. The only meaningful use of the compound operands is with the comparison operators, that is, == and !=. Two in-line compound values cannot be compared with each other because their types are unknown; at least one operand of the comparison must be a referenced value. This feature has a limitation: In the places where in-line compound templates are otherwise accepted by the syntax (e.g. in the right-hand side of a variable assignment or in the actual parameter of a function call) the referenced value shall be used as the left operand of the comparison. Otherwise the parser gets confused when seeing the comparison operator after the compound value.
+The compiler accepts in-line compound values in the operands of TTCN-3 expressions although the BNF of the standard allows only single values. The only meaningful use of the compound operands is with the comparison operators, that is, == and !=. Two in-line compound values cannot be compared with each other because their types are unknown; at least one operand of the comparison must be a referenced value. This feature has a limitation: In the places where in-line compound templates are otherwise accepted by the syntax (e.g. in the right-hand side of a variable assignment or in the actual parameter of a function call) the referenced value shall be used as the left operand of the comparison. Otherwise the parser gets confused when seeing the comparison operator after the compound value.
Examples:
[source]
@@ -174,7 +174,7 @@ control {
v_any.MyRec := { i := 42, f := 0.5 }
// ischosen(v_any.MyRec) == true
- v_any.integer := v_any.MyRec.i – 2;
+ v_any.integer := v_any.MyRec.i - 2;
// back to ischosen(v_any.integer) == true v_any.money := 0;
// local money i.e. integer
// not elsewhere.money (float)
@@ -205,18 +205,18 @@ Types imported from another module (elsewhere) can be added to the anytype of th
== Ports and Test Configurations
-If all instances of a TTCN–3 port type are intended to be used for internal communication only (i.e. between two TTCN–3 test components) the generation and linking of an empty Test Port skeleton can be avoided. If the attribute `with { extension "internal" }` is appended to the port type definition, all {cpp} code that is needed for this port will be included in the output modules.<<13-references.adoc#_9, [9]>>
+If all instances of a TTCN-3 port type are intended to be used for internal communication only (i.e. between two TTCN-3 test components) the generation and linking of an empty Test Port skeleton can be avoided. If the attribute `with { extension "internal" }` is appended to the port type definition, all {cpp} code that is needed for this port will be included in the output modules.<<13-references.adoc#_9, [9]>>
-If the user wants to use `address` values in `to` and `from` clause and sender redirect of TTCN–3 port operations the `with { extension "address" }` attribute shall be used in the corresponding port type definition(s) to generate proper {cpp} code.
+If the user wants to use `address` values in `to` and `from` clause and sender redirect of TTCN-3 port operations the `with { extension "address" }` attribute shall be used in the corresponding port type definition(s) to generate proper {cpp} code.
NOTE: When address is used in port operations the corresponding port must have an active mapping to a port of the test system interface, otherwise the operation will fail at runtime. Using of address values in to and from clauses implicitly means system as component reference. (See section "Support of address type" in <<13-references.adoc#_16, [16]>> for more details).<<13-references.adoc#_10, [10]>>
-Unlike the latest TTCN–3 standard, our run time environment allows to connect a TTCN–3 port to more than one ports of the same remote test component. When these connections persist (usually in transient states), only receiving is allowed from that remote test component, because the destination cannot be specified unambiguously in the `to` clause of the `send` operation. Similarly, it is allowed to map a TTCN–3 port to more than one ports of the system, although it is not possible to send messages to the SUT.
+Unlike the latest TTCN-3 standard, our run time environment allows to connect a TTCN-3 port to more than one ports of the same remote test component. When these connections persist (usually in transient states), only receiving is allowed from that remote test component, because the destination cannot be specified unambiguously in the `to` clause of the `send` operation. Similarly, it is allowed to map a TTCN-3 port to more than one ports of the system, although it is not possible to send messages to the SUT.
[[parameters-of-create-operation]]
== Parameters of create Operation
-The built-in TTCN–3 `create` operation can take a second, optional argument in the parentheses. The first argument, which is the part of the standard, can assign a name to the newly created test component. The optional, non-standard second argument specifies the location of the component. Also the second argument is a value or expression of type `charstring`.
+The built-in TTCN-3 `create` operation can take a second, optional argument in the parentheses. The first argument, which is the part of the standard, can assign a name to the newly created test component. The optional, non-standard second argument specifies the location of the component. Also the second argument is a value or expression of type `charstring`.
According to the standard the component name is a user-defined attribute for a test component, which can be an arbitrary string value containing any kind of characters including whitespace. It is not necessary to assign a unique name for each test component; several active test components can have the same name at the same time. The component name is not an identifier; it cannot be used to address test components in configuration operations as component references can. The name can be assigned only at component creation and it cannot be changed later.
@@ -252,30 +252,30 @@ v_myCompRef := MyCompType.create(-, "159.107.198.97") alive;
== Altsteps and Defaults
-According to the TTCN–3 standard an `altstep` can be activated as `default` only if all of its value parameters are `in` parameters. However, our compiler and run-time environment allows the activation of altsteps with `out` or `inout` value or template parameters as well. In this case the actual parameters of the activated `default` shall be the references of variables or template variables that are defined in the respective component type. This restriction is in accordance with the rules of the standard about timer parameters of activated defaults.
+According to the TTCN-3 standard an `altstep` can be activated as `default` only if all of its value parameters are `in` parameters. However, our compiler and run-time environment allows the activation of altsteps with `out` or `inout` value or template parameters as well. In this case the actual parameters of the activated `default` shall be the references of variables or template variables that are defined in the respective component type. This restriction is in accordance with the rules of the standard about timer parameters of activated defaults.
NOTE: Passing local variables or timers to defaults is forbidden because the lifespan of local definitions might be shorter than the `default` itself, which might lead to unpredictable behavior if the `default` is called after leaving the statement block that the local variable is defined in. Since ports can be defined only in component types, there is no restriction about the `port` parameters of `altsteps`. These restrictions are not applicable to direct invocations of `altsteps` (e.g. in `alt` constructs).
-The compiler allows using a statement block after `altstep` instances within `alt` statements. The statement block is executed if the corresponding `altstep` instance was chosen during the evaluation of the alt statement and the `altstep` has finished without reaching a `repeat` or `stop` statement. This language feature makes the conversion of TTCN–2 test suites easier.
+The compiler allows using a statement block after `altstep` instances within `alt` statements. The statement block is executed if the corresponding `altstep` instance was chosen during the evaluation of the alt statement and the `altstep` has finished without reaching a `repeat` or `stop` statement. This language feature makes the conversion of TTCN-2 test suites easier.
-NOTE: This construct is valid according to the TTCN–3 BNF syntax, but its semantics are not mentioned anywhere in the standard text.
+NOTE: This construct is valid according to the TTCN-3 BNF syntax, but its semantics are not mentioned anywhere in the standard text.
The compiler accepts `altsteps` containing only an `[else]` branch. This is not allowed by the BNF as every `altstep` must have at least one regular branch (which can be either a guard statement or an `altstep` instance). This construct is practically useful if the corresponding `altstep` is instantiated as the last branch of the alternative.
== Interleave Statements
-The compiler realizes TTCN–3 `interleave` statements using a different approach than it is described in section 7.5 of <<13-references.adoc#_1, [1]>>. The externally visible behavior of the generated code is equivalent to that of the canonical mapping, but our algorithm has the following advantages:
+The compiler realizes TTCN-3 `interleave` statements using a different approach than it is described in section 7.5 of <<13-references.adoc#_1, [1]>>. The externally visible behavior of the generated code is equivalent to that of the canonical mapping, but our algorithm has the following advantages:
-* Loop constructs `for`, `while` and `do-while` loops are accepted and supported without any restriction in `interleave` statements. The transformation of statements is done in a lower level than the TTCN–3 language, which does not restrict the embedded loops.
+* Loop constructs `for`, `while` and `do-while` loops are accepted and supported without any restriction in `interleave` statements. The transformation of statements is done in a lower level than the TTCN-3 language, which does not restrict the embedded loops.
* Statements `activate`, `deactivate` and `stop` can also be used within `interleave`. The execution of these statements is atomic so we did not see the reason why the standard forbids them.
* The size of our generated code is linear in contrast to the exponential code growth of the canonical algorithm. In other words, the {cpp} equivalent of every embedded statement appears exactly once in the output.
* The run-time realization does not require any extra operating system resources, such as multi-threading.
== Logging Disambiguation
-The TTCN–3 log statement provides the means to write logging information to a file or display on console (standard error). Options <<7-the_run-time_configuration_file.adoc#filemask, `FileMask`>> and <<7-the_run-time_configuration_file.adoc#consolemask, `ConsoleMask`>> determine which events will appear in the file and on the console, respectively. The generated logging messages are of type `USER_UNQUALIFIED`.
+The TTCN-3 log statement provides the means to write logging information to a file or display on console (standard error). Options <<7-the_run-time_configuration_file.adoc#filemask, `FileMask`>> and <<7-the_run-time_configuration_file.adoc#consolemask, `ConsoleMask`>> determine which events will appear in the file and on the console, respectively. The generated logging messages are of type `USER_UNQUALIFIED`.
-The `log` statement accepts among others fixed character strings TTCN–3 constants, variables, timers, functions, templates and expressions; for a complete list please refer to the table 18 in <<13-references.adoc#_1, [1]>>. It is allowed to pass multiple arguments to a single `log` statement, separated by commas.
+The `log` statement accepts among others fixed character strings TTCN-3 constants, variables, timers, functions, templates and expressions; for a complete list please refer to the table 18 in <<13-references.adoc#_1, [1]>>. It is allowed to pass multiple arguments to a single `log` statement, separated by commas.
The TTCN-3 standard does not specify how logging information should be presented. The following sections describe how TITAN implemented logging.
@@ -339,7 +339,7 @@ In case of timers the name of the timer, the default duration, the current state
== Value Returning done
-The compiler allows starting TTCN–3 functions having return type on PTCs. Those functions must have the appropriate `runs on` clause. If such a function terminates normally on the PTC, the returned value can be matched and retrieved in a `done` operation.
+The compiler allows starting TTCN-3 functions having return type on PTCs. Those functions must have the appropriate `runs on` clause. If such a function terminates normally on the PTC, the returned value can be matched and retrieved in a `done` operation.
According to the TTCN-3 standard, the value redirect in a `done` operation can only be used to store the local verdict on the PTC that executed the behavior function. In TITAN the value redirect can also be used to store the behavior function's return value with the help of an optional template argument.
@@ -349,7 +349,7 @@ The following rules apply to the optional template argument and the value redire
* The syntax of the template and value redirect is identical with that of the `receive` operation.
* If the template is present, then the type of the template and the variable used in the value redirect shall be identical. If the template is not present, then the type of the value redirect must be `verdicttype`.
-* In case of a value returning done the return type shall be a TTCN–3 type marked with the following attribute: `with { extension "done" }`. It is allowed to mark and use several types in done statements within one test suite. If the type to be used is defined in ASN.1 then a type alias shall be added to one of the TTCN–3 modules with the above attribute.
+* In case of a value returning done the return type shall be a TTCN-3 type marked with the following attribute: `with { extension "done" }`. It is allowed to mark and use several types in done statements within one test suite. If the type to be used is defined in ASN.1 then a type alias shall be added to one of the TTCN-3 modules with the above attribute.
* In case of a value returning done the type of the template or variable must be visible from the module where the `done` statement is used.
* Only those done statements can have a template or a value redirect that refer to a specific PTC component reference. That is, it is not allowed to use this construct with `any component.done` or `all component.done`.
@@ -399,7 +399,7 @@ testcase myTestCase2() runs on AnotherCompType
== Dynamic Templates
-Dynamic templates (template variables, functions returning templates and passing template variables by reference) are now parts of the TTCN–3 Core Language standard (<<13-references.adoc#_1, [1]>>). These constructs have been added to the standard with the same syntax and semantics as they were supported in this Test Executor. Thus dynamic templates are not considered language extensions anymore.
+Dynamic templates (template variables, functions returning templates and passing template variables by reference) are now parts of the TTCN-3 Core Language standard (<<13-references.adoc#_1, [1]>>). These constructs have been added to the standard with the same syntax and semantics as they were supported in this Test Executor. Thus dynamic templates are not considered language extensions anymore.
However, there is one extension compared to the supported version of Core Language. Unlike the standard, the compiler and the run-time environment allow the external functions to return templates.
@@ -476,11 +476,11 @@ DTE occurs if the `invalue` does not conform to UTF standards. The `oct2unichar`
Any code unit greater than 0x10FFFF is ill-formed.
-UTF-32 code units in the range of 0x0000D800 – 0x0000DFFF are ill-formed.
+UTF-32 code units in the range of 0x0000D800 - 0x0000DFFF are ill-formed.
-UTF-16 code units in the range of 0xD800 – 0xDFFF are ill-formed.
+UTF-16 code units in the range of 0xD800 - 0xDFFF are ill-formed.
-UTF-8 code units in the range of 0xD800 – 0xDFFF are ill-formed.
+UTF-8 code units in the range of 0xD800 - 0xDFFF are ill-formed.
Example:
----
@@ -539,7 +539,7 @@ the resulting nobom contains: 'C384C396C39CC3A4C3B6C3BC'O;
== Additional Predefined Functions
-In addition to standardized TTCN–3 predefined functions given in Annex C of <<13-references.adoc#_1, [1]>> and Annex B of <<13-references.adoc#_3, [3]>> the following built-in conversion functions are supported by our compiler and run-time environment:
+In addition to standardized TTCN-3 predefined functions given in Annex C of <<13-references.adoc#_1, [1]>> and Annex B of <<13-references.adoc#_3, [3]>> the following built-in conversion functions are supported by our compiler and run-time environment:
=== `str2bit`
@@ -810,10 +810,10 @@ The boundary values used to specify range subtypes can be preceded by an exclama
[[special-float-values-infinity-and-not-a-number]]
== Special Float Values Infinity and not_a_number
-The keyword infinity (which is also used to specify value range and size limits) can be used to specify the special float values –infinity and +infinity, these are equivalent to MINUS-INFINITY and PLUS-INFINITY used in ASN.1. A new keyword not_a_number has been introduced which is equivalent to NOT-A-NUMBER used in ASN.1. The -infinity and +infinity and not_a_number special values can be used in arithmetic operations. If an arithmetic operation's operand is not_a_number then the result of the operation will also be not_a_number. The special value not_a_number cannot be used in a float range subtype because it's an unordered value, but can be added as a single value, for example subtype (0.0 .. infinity, not_a_number) contains all positive float values and the not_a_number value.
+The keyword infinity (which is also used to specify value range and size limits) can be used to specify the special float values -infinity and +infinity, these are equivalent to MINUS-INFINITY and PLUS-INFINITY used in ASN.1. A new keyword not_a_number has been introduced which is equivalent to NOT-A-NUMBER used in ASN.1. The -infinity and +infinity and not_a_number special values can be used in arithmetic operations. If an arithmetic operation's operand is not_a_number then the result of the operation will also be not_a_number. The special value not_a_number cannot be used in a float range subtype because it's an unordered value, but can be added as a single value, for example subtype (0.0 .. infinity, not_a_number) contains all positive float values and the not_a_number value.
[[ttcn-3-preprocessing]]
-== TTCN–3 Preprocessing
+== TTCN-3 Preprocessing
Preprocessing of the TTCN-3 files with a C preprocessor is supported by the compiler. External preprocessing is used: the Makefile Generator generates a `Makefile` which will invoke the C preprocessor to preprocess the TTCN-3 files with the suffix `."ttcnpp`. The output of the C preprocessor will be generated to an intermediate file with the suffix `."ttcn`. The intermediate files contain the TTCN-3 source code and line markers. The compiler can process these line markers along with TTCN-3. If the preprocessing is done with the `-P` option <<13-references.adoc#_13, [13]>>, the resulting code will not contain line markers; it will be compatible with any standard TTCN-3 compiler. The compiler will use the line markers to give almost <<13-references.adoc#_14, [14]>> correct error or warning messages, which will point to the original locations in the `.ttcnpp` file. The C preprocessor directive `#"include` can be used in .ttcnpp files; the Makefile Generator will treat all files with suffix `."ttcnin` as TTCN-3 include files. The `."ttcnin` files will be added to the Makefile as special TTCN-3 include files which will not be translated by the compiler, but will be checked for modification when building the test suite.
@@ -889,7 +889,7 @@ myFunction(p_par2 := false, 1); // unnamed part cannot follow
Although TITAN supports the behaviour type package (<<13-references.adoc#_5, [5]>>) of the TTCN-3 standard, but this feature was included in the standard with a different syntax.
-It is allowed to create TTCN–3 types of `functions`, `altsteps` and `testcases`. Values, for example variables, of such types can carry references to the respective TTCN–3 definitions. To facilitate reference using, three new operations (`refers`, `derefers` and `apply`) were introduced. This new language feature allows to create generic algorithms in TTCN–3 with late binding, (i.e. code in which the function to be executed is specified only at runtime).
+It is allowed to create TTCN-3 types of `functions`, `altsteps` and `testcases`. Values, for example variables, of such types can carry references to the respective TTCN-3 definitions. To facilitate reference using, three new operations (`refers`, `derefers` and `apply`) were introduced. This new language feature allows to create generic algorithms in TTCN-3 with late binding, (i.e. code in which the function to be executed is specified only at runtime).
[[function-types-with-a-runson-self-clause]]
== Function Types with a RunsOn_self Clause
@@ -995,35 +995,35 @@ function f_MyCallbackFunction () runs on User_CT
----
[[ttcn3-macros]]
-== TTCN–3 Macros
+== TTCN-3 Macros
-The compiler and the run-time environment support the following non-standard macro notation in TTCN–3 modules. All TTCN–3 macros consist of a percent (%) character followed by the macro identifier. Macro identifiers are case sensitive. The table below summarizes the available macros and their meaning. Macro identifiers not listed here are reserved for future extension.
+The compiler and the run-time environment support the following non-standard macro notation in TTCN-3 modules. All TTCN-3 macros consist of a percent (%) character followed by the macro identifier. Macro identifiers are case sensitive. The table below summarizes the available macros and their meaning. Macro identifiers not listed here are reserved for future extension.
.TTCN-3 macros
[cols=",",options="header",]
|===
|Macro |Meaning
-|`%moduleId` |name of the TTCN–3 module
-|`%definitionId` |name of the top-level TTCN–3 definition
+|`%moduleId` |name of the TTCN-3 module
+|`%definitionId` |name of the top-level TTCN-3 definition
|`%testcaseId` |name of the test case that is currently being executed
-|`%fileName` |name of the TTCN–3 source file
+|`%fileName` |name of the TTCN-3 source file
|`%lineNumber` |number of line in the source file
|===
The following rules apply to macros:
* All macros are substituted with a value of type `charstring`. They can be used as operands of complex expressions (concatenation, comparison, etc.).
-* All macros except `%testcaseId` are evaluated during compilation and they can be used anywhere in the TTCN–3 module.
+* All macros except `%testcaseId` are evaluated during compilation and they can be used anywhere in the TTCN-3 module.
* Macro `%testcaseId` is evaluated at runtime. It can be used only within functions and altsteps that are being run on test components (on the MTC or PTCs) and within testcases. It is not allowed to use macro `%testcaseId` in the module control part. If a function or altstep that contains macro `%testcaseId` is called directly from the control part the evaluation of the macro results in a dynamic test case error.
-* The result of macro `%testcaseId` is not a constant thus it cannot be used in the value of TTCN–3 constants. It is allowed only in those contexts where TTCN–3 variable references are permitted.
+* The result of macro `%testcaseId` is not a constant thus it cannot be used in the value of TTCN-3 constants. It is allowed only in those contexts where TTCN-3 variable references are permitted.
* Macro `%definitionId` is always substituted with the name of the top-level module definition that it is used in. <<13-references.adoc#_15, [15]>> For instance, if the macro appears in a constant that is defined within a function then the macro will be substituted with the function's name rather than the one of the constant. When used within the control part macro `%definitionId` is substituted with the word "`control`".
* Macro `%fileName` is substituted with the name of the source file in the same form as it was passed to the compiler. This can be a simple file name, a relative or an absolute path name.
* The result of macro `%lineNumber` is always a string that contains the current line number as a decimal number. Numbering of lines starts from 1. All lines of the input file (including comments and empty lines) are counted. When it needs to be used in an integer expression a conversion is necessary: `str2int(%lineNumber)`. The above expression is evaluated during compilation without any runtime performance penalty.
-* Source line markers are considered when evaluating macros `%fileName` and `%lineNumber`. In preprocessed TTCN–3 modules the macros are substituted with the original file name and line number that the macro comes from provided that the preprocessor supports it.
+* Source line markers are considered when evaluating macros `%fileName` and `%lineNumber`. In preprocessed TTCN-3 modules the macros are substituted with the original file name and line number that the macro comes from provided that the preprocessor supports it.
* When macros are used in `log()` statements, they are treated like literal strings rather than charstring value references. That is, quotation marks around the strings are not used and special characters within them are not escaped in the log file.
* For compatibility with the C preprocessor the compiler also recognizes the following C style macros: \\__FILE__ is identical to `%fileName` and \\__LINE__ is identical to `str2int(%lineNumber)`.
* Macros are not substituted within quotation marks (i.e. within string literals and attributes).
-* The full power of TTCN–3 macros can be exploited in combination with the C preprocessor.
+* The full power of TTCN-3 macros can be exploited in combination with the C preprocessor.
Example:
[source]
@@ -1072,7 +1072,7 @@ type component B extends A {
}
----
-In order to provide support for existing TTCN–3 code (e.g. standardized test suites) it is allowed to explicitly signal the compatibility relation between component types using a special `extension` attribute. Using such attributes shall be avoided in newly written TTCN–3 modules. Combining component type inheritance and the attribute `extension` is possible, but not recommended.
+In order to provide support for existing TTCN-3 code (e.g. standardized test suites) it is allowed to explicitly signal the compatibility relation between component types using a special `extension` attribute. Using such attributes shall be avoided in newly written TTCN-3 modules. Combining component type inheritance and the attribute `extension` is possible, but not recommended.
Thus, the compiler considers component type B to be compatible with A if B has an `extension` attribute that points to A as base component type and all definitions of A are present and identical in B.
@@ -1138,14 +1138,14 @@ All component types are compatible with each empty component type. Empty compone
== Implicit Message Encoding
-The TTCN–3 standard <<13-references.adoc#_1, [1]>> does not specify a standard way of data encoding/decoding. TITAN has a common {cpp} API for encoding/decoding; to use this API external functions are usually needed. The common solution is to define a TTCN–3 external function and write the {cpp} code containing the API calls. In most cases the {cpp} code explicitly written to an auxiliary {cpp} file contains only simple code patterns which call the encoding/decoding API functions on the specified data. In TITAN there is a TTCN–3 language extension which automatically generates such external functions.
+The TTCN-3 standard <<13-references.adoc#_1, [1]>> does not specify a standard way of data encoding/decoding. TITAN has a common {cpp} API for encoding/decoding; to use this API external functions are usually needed. The common solution is to define a TTCN-3 external function and write the {cpp} code containing the API calls. In most cases the {cpp} code explicitly written to an auxiliary {cpp} file contains only simple code patterns which call the encoding/decoding API functions on the specified data. In TITAN there is a TTCN-3 language extension which automatically generates such external functions.
-Based on this automatic encoding/decoding mechanism, dual-faced ports are introduced. Dual-faced ports have an external and an internal interface and can automatically transform messages passed through them based on mapping rules defined in TTCN–3 source files. These dual-faced ports eliminate the need for simple port mapping components and thus simplify the test configuration.
+Based on this automatic encoding/decoding mechanism, dual-faced ports are introduced. Dual-faced ports have an external and an internal interface and can automatically transform messages passed through them based on mapping rules defined in TTCN-3 source files. These dual-faced ports eliminate the need for simple port mapping components and thus simplify the test configuration.
[[dual-faced-ports]]
=== Dual-faced Ports
-In the TTCN–3 standard (<<13-references.adoc#_1, [1]>>), a port type is defined by listing the allowed incoming and outgoing message types. Dual-faced ports have on the other hand two different message lists: one for the external and one for the internal interface. External and internal interfaces are given in two distinct port type definitions. The dual-faced concept is applicable to message based ports and the message based part of mixed ports.
+In the TTCN-3 standard (<<13-references.adoc#_1, [1]>>), a port type is defined by listing the allowed incoming and outgoing message types. Dual-faced ports have on the other hand two different message lists: one for the external and one for the internal interface. External and internal interfaces are given in two distinct port type definitions. The dual-faced concept is applicable to message based ports and the message based part of mixed ports.
Dual-faced port types must have `user` attribute to designate its external interface. The internal interface is given by the port type itself. A port type can be the external interface of several different dual-faced port types.
@@ -1224,7 +1224,7 @@ NOTE: Decoding with sliding should be the last decoding option in the list of de
Encoder/decoder functions are used to convert between different data (message) structures. We can consider e.g. an octet string received from the remote system that should be passed to the upper layer as a TCP message.
-Prototypes are attributes governing data input/output rules and conversion result indication. In other words, prototypes are setting the data interface types. The compiler will verify that the parameters and return value correspond to the given prototype. Any TTCN–3 function (even external ones) may be defined with a prototype. There are four prototypes defined as follows:
+Prototypes are attributes governing data input/output rules and conversion result indication. In other words, prototypes are setting the data interface types. The compiler will verify that the parameters and return value correspond to the given prototype. Any TTCN-3 function (even external ones) may be defined with a prototype. There are four prototypes defined as follows:
* prototype `convert`
+
@@ -1346,7 +1346,7 @@ The TITAN codec API has some well defined function calls that control the behavi
Possible error types and error handlings are defined in <<13-references.adoc#\_16, [16]>>, section "The common API". The value of `<error_type>` shall be a value of type `error_type_t` without the prefix `ET_`. The value of `<error_handling>` shall be a value of type `error_behavior_t` without the prefix `EB_`.
-The TTCN–3 attribute `errorbehavior(INCOMPL_ANY:ERROR)`, for example, will be mapped to the following {cpp} statement:
+The TTCN-3 attribute `errorbehavior(INCOMPL_ANY:ERROR)`, for example, will be mapped to the following {cpp} statement:
[source]
----
TTCN_EncDec::set_error_behavior(TTCN_EncDec::ET_INCOMPL_ANY,
@@ -1558,16 +1558,16 @@ var integer res := decvalue(bs, y); // equivalent to f_dec_per(bs, y);
=== Common Syntax of Attributes
-All information related to implicit message encoding shall be given as `extension` attributes of the relevant TTCN–3 definitions. The attributes have a common basic syntax, which is applicable to all attributes given in this section:
+All information related to implicit message encoding shall be given as `extension` attributes of the relevant TTCN-3 definitions. The attributes have a common basic syntax, which is applicable to all attributes given in this section:
-* Whitespace characters (spaces, tabulators, newlines, etc.) and TTCN–3 comments are allowed anywhere in the attribute text. Attributes containing only comments, whitespace or both are simply ignored +
+* Whitespace characters (spaces, tabulators, newlines, etc.) and TTCN-3 comments are allowed anywhere in the attribute text. Attributes containing only comments, whitespace or both are simply ignored +
Example: +
`with { extension "/* this is a comment */" }`
-* When a definition has multiple attributes, the attributes can be given either in one attribute text separated by whitespace or in separate TTCN–3 attributes. +
+* When a definition has multiple attributes, the attributes can be given either in one attribute text separated by whitespace or in separate TTCN-3 attributes. +
Example: +
`with { extension "address provider" }` means exactly the same as +
`with { extension "address"; extension "provider" }`
-* Settings for a single attribute, however, cannot be split in several TTCN–3 attributes. +
+* Settings for a single attribute, however, cannot be split in several TTCN-3 attributes. +
Example of an invalid attribute: +
`with { extension "prototype("; extension "convert)" }`
* Each kind of attribute can be given at most once for a definition. +
@@ -1577,13 +1577,13 @@ Example of an invalid attribute: +
Example: +
`with { extension "prototype(fast) encode(RAW)" }` means exactly the same as +
`with { extension "encode(RAW) prototype(fast)" }`
-* The keywords introduced in this section, which are not TTCN–3 keywords, are not reserved words. The compiler will recognize the word properly if it has a different meaning (e.g. the name of a type) in the given context. +
+* The keywords introduced in this section, which are not TTCN-3 keywords, are not reserved words. The compiler will recognize the word properly if it has a different meaning (e.g. the name of a type) in the given context. +
Example: the attribute +
`with { extension "user provider in(internal -> simple: function(prototype))" }` can be a valid if there is a port type named `provider`; `internal` and `simple` are message types and `prototype` is the name of a function.
=== API describing External Interfaces
-Since the default class hierarchy of test ports does not allow sharing of {cpp} code with other port types, an alternate internal API is introduced for port types describing external interfaces. This alternate internal API is selected by giving the appropriate TTCN–3 extension attribute to the port. The following extension attributes or attribute combinations can be used:
+Since the default class hierarchy of test ports does not allow sharing of {cpp} code with other port types, an alternate internal API is introduced for port types describing external interfaces. This alternate internal API is selected by giving the appropriate TTCN-3 extension attribute to the port. The following extension attributes or attribute combinations can be used:
.Port extension attributes
[cols=",,,,,",options="header",]
@@ -1735,7 +1735,7 @@ The decoder, on the contrary, converts the received bitstream into values of abs
This section covers the <<general-rules-and-restrictions, coding rules in general>>, the <<attributes, attributes controlling them>> and the <<ttcn-3-types-and-their-attributes, attributes allowed for a particular type>>.
-You can use the encoding rules defined in this section to encode and decode the following TTCN–3 types:
+You can use the encoding rules defined in this section to encode and decode the following TTCN-3 types:
* bitstring
* boolean
@@ -1928,7 +1928,7 @@ Description: `FIELDLENGTH` specifies the length of the encoded type. The units o
The value 0 means variable length or, in case of the enumerated type, the minimum number of bits required to display the maximum `enumerated` value. `Integer` cannot be coded with variable length.
-NOTE: If `FIELDLENGTH` is not specified, but a TTCN–3 length restriction with a fixed length is, then the restricted length will be used as `FIELDLENGTH`.
+NOTE: If `FIELDLENGTH` is not specified, but a TTCN-3 length restriction with a fixed length is, then the restricted length will be used as `FIELDLENGTH`.
Examples:
[source]
@@ -1986,7 +1986,7 @@ Description: This attribute sets the `FIELDLENGTH`, `BYTEORDER` and `COMP` attri
`octetstring, charstring:` N / 8; +
`hexstring:` N / 4.
-NOTE: If `FIELDLENGTH` is not specified, but a TTCN–3 length restriction with a fixed length is, then the restricted length will be used as `FIELDLENGTH`.
+NOTE: If `FIELDLENGTH` is not specified, but a TTCN-3 length restriction with a fixed length is, then the restricted length will be used as `FIELDLENGTH`.
The `[unsigned] <parameter> bits` syntax is also supported but the usage of `bit` keyword is preferred.
@@ -2960,7 +2960,7 @@ field2:='10010011'B
This section describes the coding attributes of fields containing length information or serving as pointer within a `record`.
-The length and pointer fields must be of TTCN–3 `integer` type and must have fixed length.
+The length and pointer fields must be of TTCN-3 `integer` type and must have fixed length.
The attributes described in this section are applicable to fields of a `record`.
@@ -2968,7 +2968,7 @@ The attributes described in this section are applicable to fields of a `record`.
Attribute syntax: `LENGTHTO(<parameter>) [ (`+' | `-') <offset> ]`
-Parameters allowed: list of TTCN–3 field identifiers
+Parameters allowed: list of TTCN-3 field identifiers
Parameter value: any field name
@@ -2982,7 +2982,7 @@ Description: The encoder is able to calculate the encoded length of one or sever
If the offset is present, it is added to or subtracted from (the operation specified in the attribute is performed) the calculated length during encoding. During decoding, the offset is subtracted from or added to (the opposite operation to the one specified in the attribute is performed) the decoded value of the length field.
-NOTE: The length is expressed in units defined by the attribute UNIT The default unit is octet. The length field should be a TTCN–3 `integer` or `union` type. Special union containing only integer fields can be used for variable length field. It must not be used with `LENGTHINDEX`. The length field can be included in to the sum of the lengths of multiple fields (e.g. `lengthField` + `field2` + `field3`). The `union` field is NOT selected by the encoder. So the suitable field must be selected before encoding! The fields included in the length computing need not be continuous.
+NOTE: The length is expressed in units defined by the attribute UNIT The default unit is octet. The length field should be a TTCN-3 `integer` or `union` type. Special union containing only integer fields can be used for variable length field. It must not be used with `LENGTHINDEX`. The length field can be included in to the sum of the lengths of multiple fields (e.g. `lengthField` + `field2` + `field3`). The `union` field is NOT selected by the encoder. So the suitable field must be selected before encoding! The fields included in the length computing need not be continuous.
Examples:
[source]
@@ -3097,7 +3097,7 @@ variant (len) "LENGTHTO(field) - 2"
Attribute syntax: `LENGTHINDEX(<parameter>)`
-Parameters allowed: TTCN–3 field identifier
+Parameters allowed: TTCN-3 field identifier
Allowed values: any nested field name
@@ -3108,7 +3108,7 @@ Can be used with: fields of a `record`.
Description: This attribute extends the `LENGTHTO` attribute with the identification of the nested field containing the length value within the field of the corresponding `LENGTHTO` attribute.
Comment: See also the description of the `LENGTHTO` attribute.
-NOTE: The field named by `LENGTHINDEX` attribute should be a TTCN–3 integer type.
+NOTE: The field named by `LENGTHINDEX` attribute should be a TTCN-3 integer type.
Example (see also example of `LENGTHTO` attribute).
[source]
@@ -3138,7 +3138,7 @@ variant (lengthRec) "LENGTHINDEX(length)"
Attribute syntax: `POINTERTO(<parameter>)`
-Parameters allowed: TTCN–3 field identifier
+Parameters allowed: TTCN-3 field identifier
Default value: none
@@ -3147,7 +3147,7 @@ Can be used with: fields of a `record`.
Description: Some record fields contain the distance to another encoded field. Records can be encoded in the form of: `ptr1`, `ptr2`, `ptr3`, `field1`, `field2`, `field3`, where the position of fieldN within the encoded stream can be determined from the value and position of field ptrN. The distance of the pointed field from the base field will be `ptrN` * `UNIT` + `PTROFFSET`. The default base field is the pointer itself. The base field can be set by the PTROFFSET attribute. When the pointed field is optional, the pointer value 0 indicates the absence of the pointed field.
Comment: See also the description of `UNIT` (0) and `PTROFFSET` (0) attributes.
-NOTE: Pointer fields should be TTCN–3 `integer` type.
+NOTE: Pointer fields should be TTCN-3 `integer` type.
Examples:
[source]
@@ -3186,7 +3186,7 @@ field3 := '070809'O
Attribute syntax: `PTROFFSET(<parameter>)`
-Parameters allowed: `integer`, TTCN–3 field identifier
+Parameters allowed: `integer`, TTCN-3 field identifier
Default value: 0
@@ -3290,7 +3290,7 @@ Default value: none
Can be used with: `optional` fields of a `record` or `set`.
-Description: Within records some fields may indicate the presence of another optional field. The attribute `PRESENCE` is used to describe these cases. Each optional field can have a `PRESENCE` definition. The syntax of the `PRESENCE` attribute is the following: a `PRESENCE` definition is a presence_indicator expression. `Presence_indicators` are of form `<key> = <constant> or {<key1> = <constant1>, <key2> = <constant2>, … <keyN> = <constantN>}` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN–3 constant expression (for example, `22`, `'25'O` or `'1001101'B`).
+Description: Within records some fields may indicate the presence of another optional field. The attribute `PRESENCE` is used to describe these cases. Each optional field can have a `PRESENCE` definition. The syntax of the `PRESENCE` attribute is the following: a `PRESENCE` definition is a presence_indicator expression. `Presence_indicators` are of form `<key> = <constant> or {<key1> = <constant1>, <key2> = <constant2>, … <keyN> = <constantN>}` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN-3 constant expression (for example, `22`, `'25'O` or `'1001101'B`).
NOTE: The PRESENCE attribute can identify the presence of the whole record. In that case the field reference must be omitted.
@@ -3322,7 +3322,7 @@ Default value: none
Can be used with: `record` or `set`.
-Description: The purpose of the attribute `TAG` is to identify specific values in certain fields of the `set`, `record` elements or `union` choices. When the `TAG` is specified to a `record` or a `set`, the presence of the given element can be identified at decoding. When the `TAG` belongs to a `union`, the union member can be identified at decoding. The attribute is a list of `field_identifications`. Each `field_identification` consists of a record, set or union field name and a `presence_indicator` expression separated by a comma (,). `Presence_indicators` are of form `<key> = <constant>` or `{ <key1> = <constant1>, <key2> = <constant2>, … <keyN> = <constantN> }` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN–3 constant expression (e.g.` 22`, `'25'O` or `'1001101'B`).There is a special presence_indicator: `OTHERWISE`. This indicates the default union member in a union when the TAG belongs to union.
+Description: The purpose of the attribute `TAG` is to identify specific values in certain fields of the `set`, `record` elements or `union` choices. When the `TAG` is specified to a `record` or a `set`, the presence of the given element can be identified at decoding. When the `TAG` belongs to a `union`, the union member can be identified at decoding. The attribute is a list of `field_identifications`. Each `field_identification` consists of a record, set or union field name and a `presence_indicator` expression separated by a comma (,). `Presence_indicators` are of form `<key> = <constant>` or `{ <key1> = <constant1>, <key2> = <constant2>, … <keyN> = <constantN> }` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN-3 constant expression (e.g.` 22`, `'25'O` or `'1001101'B`).There is a special presence_indicator: `OTHERWISE`. This indicates the default union member in a union when the TAG belongs to union.
NOTE: `TAG` works on non-optional fields of a record as well. It is recommended to use the attributes `CROSSTAG` or `PRESENCE` leading to more effective decoding.
@@ -3386,7 +3386,7 @@ Default value: none
Can be used with: `union` fields of `records`.
-Description: When one field of a `record` specifies the union member of another field of a record, CROSSTAG definition is used. The syntax of the CROSSTAG attribute is the following. Each union field can have a `CROSSTAG` definition. A `CROSSTAG` definition is a list of union `field_identifications`. Each `field_identification` consists of a union field name and a `presence_indicator` expression separated by a comma (,). `Presence_indicators` are of form `<key> = <constant>` or `{<key1> = <constant1>`, `<key2> = <constant2>`, `… <keyN> = <constantN>}` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN–3 constant expression (for example, `22`, `'25'O` or `'1001101'B`).There is a special `presence_indicator`: `OTHERWISE`. This indicates the default union member in union.
+Description: When one field of a `record` specifies the union member of another field of a record, CROSSTAG definition is used. The syntax of the CROSSTAG attribute is the following. Each union field can have a `CROSSTAG` definition. A `CROSSTAG` definition is a list of union `field_identifications`. Each `field_identification` consists of a union field name and a `presence_indicator` expression separated by a comma (,). `Presence_indicators` are of form `<key> = <constant>` or `{<key1> = <constant1>`, `<key2> = <constant2>`, `… <keyN> = <constantN>}` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN-3 constant expression (for example, `22`, `'25'O` or `'1001101'B`).There is a special `presence_indicator`: `OTHERWISE`. This indicates the default union member in union.
NOTE: The difference between the `TAG` and `CROSSTAG` concept is that in case of `TAG` the field identifier is inside the field to be identified. In case of `CROSSTAG` the field identifier can either precede or succeed the union field it refers to. If the field identifier succeeds the union, they must be in the same record, the union field must be mandatory and all of its embedded types must have the same fixed size.
@@ -4192,7 +4192,7 @@ Error encountered during the encoding or decoding process are handled as defined
An `attribute` determines coding and encoding rules.
-NOTE: the section 27.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>) states that an `attribute` is used to refine the current encoding scheme defined with the keyword `encode`. Because of backward compatibility the presence of the `encode` attribute is not required, but might result in a compile time warning (which in the future might turn into an error).
+NOTE: the section 27.5 of the TTCN-3 standard (<<13-references.adoc#_1, [1]>>) states that an `attribute` is used to refine the current encoding scheme defined with the keyword `encode`. Because of backward compatibility the presence of the `encode` attribute is not required, but might result in a compile time warning (which in the future might turn into an error).
*BEGIN*
@@ -4206,7 +4206,7 @@ Parameters: `token_to_encode` +
The token is used during encoding. +
`Mandatory.matching_exp` +
-This TTCN–3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>). This parameter is optional; when omitted, the parameter token_to_encode will be used as the matching pattern. +
+This TTCN-3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN-3 standard (<<13-references.adoc#_1, [1]>>). This parameter is optional; when omitted, the parameter token_to_encode will be used as the matching pattern. +
`modifier` +
Modifies the behavior of the matching algorithm. Optional parameter. When omitted the default value will be used. The available modifiers: +
@@ -4247,7 +4247,7 @@ Parameters: `token_to_encode` +
The token used during encoding. Mandatory.
`matching_exp` +
-This TTCN–3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>). This parameter is optional; when omitted, the `token_to_encode` will be used as matching pattern.
+This TTCN-3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN-3 standard (<<13-references.adoc#_1, [1]>>). This parameter is optional; when omitted, the `token_to_encode` will be used as matching pattern.
`modifier` +
Modifies the behavior of the matching algorithm. Optional parameter. When omitted, the default value will be used. The available modifiers: +
@@ -4287,7 +4287,7 @@ Parameters: `token_to_encode` +
The token used during encoding. Mandatory.
`matching_exp` +
-This TTCN–3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>). Optional parameter. When omitted, the token to encode will be used as matching pattern.
+This TTCN-3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN-3 standard (<<13-references.adoc#_1, [1]>>). Optional parameter. When omitted, the token to encode will be used as matching pattern.
`modifier` +
Modifies the behavior of the matching algorithm. Optional parameter. When omitted, the default value will be used. The available modifiers: +
@@ -4328,7 +4328,7 @@ Controls the encoding of the value. For syntax see the two tables below.
Controls the decoding of the value. For syntax see the two tables below.
`matching_exp` +
-TTCN–3 character pattern, used during decoding to identify the value of the type. The format of the parameter is described in clause B.1.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>). Optional parameter.
+TTCN-3 character pattern, used during decoding to identify the value of the type. The format of the parameter is described in clause B.1.5 of the TTCN-3 standard (<<13-references.adoc#_1, [1]>>). Optional parameter.
`modifier` +
Modifies the behavior of the matching algorithm. Optional parameter. When omitted, the default value will be used. The available modifiers: +
@@ -4358,7 +4358,7 @@ The default encoded value of `true` is 'true'; the default encoded value of `fal
The default decoding method is case sensitive
|`enumerated` |The encoded value of enumeration: +
`value:'token'[;value:'token']` +
-The default encoded value of enumerations is the TTCN–3 identifier of the enumerations.
+The default encoded value of enumerations is the TTCN-3 identifier of the enumerations.
|The matching pattern of enumerations: +
`value:{'pattern'[,modifier]}[;value:{'pattern'[,modifier]}]`
The default decoding method is case sensitive.
@@ -4499,7 +4499,7 @@ The XML encoder and decoder are handling XML-based protocols. The encoder conver
The TTCN-3 standard defines a mechanism using attributes to define encoding variants. The attributes concerning the XML encoding are standardized in <<13-references.adoc#_4, [4]>> (annex B of the standard lists the attributes and their effects).
-Faults in the XML encoding/decoding process are set to error by default, but it can be modified with the `errorbehavior` TTCN–3 attribute. (<<codec-error-handling, Codec error handling>>)
+Faults in the XML encoding/decoding process are set to error by default, but it can be modified with the `errorbehavior` TTCN-3 attribute. (<<codec-error-handling, Codec error handling>>)
[[attributes-1]]
=== Attributes
@@ -5394,7 +5394,7 @@ This section covers the coding rules in general, the attributes controlling them
[[general-rules-and-restrictions-1]]
=== General rules and restrictions
-You can use the encoding rules defined in this section to encode and decode the following TTCN–3 types:
+You can use the encoding rules defined in this section to encode and decode the following TTCN-3 types:
* anytype
* array
@@ -6009,11 +6009,11 @@ The option `-j` restricts the TTCN-3 types used in the conversion: only those th
If option `-f` is set, then the schema will only validate types that have JSON encoding and/or decoding functions, otherwise all types it will validate all types included in the schema.
-The options `-A` and `-T` can be used before each input file to specify its type (`-A` for ASN.1 files and `–T` for TTCN-3 files). If a file is not preceeded by either of these option, then the compiler will attempt to determine its type based on its contents.
+The options `-A` and `-T` can be used before each input file to specify its type (`-A` for ASN.1 files and `-T` for TTCN-3 files). If a file is not preceeded by either of these option, then the compiler will attempt to determine its type based on its contents.
The last parameter specifies the name of the JSON schema file if it is preceded by a dash (-). Otherwise the name of the schema will be created using the first input file name (its `.asn` or `.ttcn` extension will be replaced by `.json`, or, if it doesn't have either of these extension, then `.json` will simply be appended to its end).
-Usage examples:compiler –ttcn2json –T module1.ttcn –A module2.asn – schema.jsoncompiler –-ttcn2json –j module1.ttcn module2.asn
+Usage examples:compiler -ttcn2json -T module1.ttcn -A module2.asn - schema.jsoncompiler --ttcn2json -j module1.ttcn module2.asn
The first example will generate the `schema.json` JSON document containing the schema, the second one will generate `module1.json` (and only JSON-encodable types will be included). These documents will have the "pretty" printing format mentioned in 4.26.3.
@@ -6024,7 +6024,7 @@ On the top level the schema contains a JSON object with 2 properties.
The first property, "definitions", has the schema segments of the type definitions in the TTCN-3 and ASN.1 modules as its value. This value is a JSON object with one property (key-value pair) for each module. Each property has the module name as its key and an object containing the schema segments for the types definied in that module as its key. Similarly, each type definition's key is the type name and its value is the type's schema segment (these will be described in the next sections).
-The second top level property is an "anyOf" structure, which contains references to the TTCN-3 and ASN.1 types' schema segments under "definitions". The types listed here are the ones validated by the schema. If the compiler option `–f` is set, then only the schema segments of types that have either a JSON encoding or decoding function (or both) will be referenced (ASN.1 types can have JSON encoding/decoding functions declared in TTCN-3 modules that import them). Extra information related to the encoding/decoding function(s) is stored after each reference.
+The second top level property is an "anyOf" structure, which contains references to the TTCN-3 and ASN.1 types' schema segments under "definitions". The types listed here are the ones validated by the schema. If the compiler option `-f` is set, then only the schema segments of types that have either a JSON encoding or decoding function (or both) will be referenced (ASN.1 types can have JSON encoding/decoding functions declared in TTCN-3 modules that import them). Extra information related to the encoding/decoding function(s) is stored after each reference.
Example:
[source]
@@ -6105,7 +6105,7 @@ The JSON schema will be generated according to the rules of the IETF draft v4 (s
In addition to the "definitions" keyword specified above, the schema segments of the type definitions can use the following extra keywords:
* `"subType"`: distinguishes 2 or more types from each other, that otherwise have no other differences in their schema segments (such as: charstring and universal charstring; record and set; record of and set of)
-* `"fieldOrder"`: stores the order of the fields of a record or set (value: an array containing the field names) – only needed if there are at least 2 fields
+* `"fieldOrder"`: stores the order of the fields of a record or set (value: an array containing the field names) - only needed if there are at least 2 fields
* `"originalName"`: stores the original name of a record/set field (see <<effect-of-coding-instructions-on-the-schema, here>>)
* `"unusedAlias"`: stores the alias of a record/set/union field name, if it doesn't appear under a "properties" keyword (see <<effect-of-coding-instructions-on-the-schema, here>>)
* `"omitAsNull"`: specifies if the "omit as null" JSON encoding instruction is present for an optional field of a record or set (see <<schema-segments-for-records-and-sets, here>> and <<effect-of-coding-instructions-on-the-schema, here>>)
@@ -6673,13 +6673,13 @@ NumRec ::= rec < Thing
For the list of JSON coding instructions see <<attributes-1, here>>. As mentioned before, only TTCN-3 types can have coding instructions, ASN.1 types can't.
-* _omit as null_ – its presence is indicated by the "omitAsNull" keyword (true, if it's present)
+* _omit as null_ - its presence is indicated by the "omitAsNull" keyword (true, if it's present)
* _name as …_ - the alias is used under "properties" instead of the field's name in TTCN-3; the original name is stored under the "originalName" key
-* _as value_ – the union's "anyOf" structure contains the fields' schema segments instead of the JSON objects with one property; the field's name is stored under the "originalName" key
-* _default_ – specified by the "default" keyword
-* _extend_ – adds a custom key-value pair to the type's schema segment
+* _as value_ - the union's "anyOf" structure contains the fields' schema segments instead of the JSON objects with one property; the field's name is stored under the "originalName" key
+* _default_ - specified by the "default" keyword
+* _extend_ - adds a custom key-value pair to the type's schema segment
* _as value_ + _name as …_ - the field name aliases are stored under the "unusedAlias" keyword, as there are no more JSON objects with one property to store them in (they are also ignored by both the schema and the encoder/decoder, and a compiler warning is displayed in this case)
-* _metainfo for unbound_ – is ignored by the schema generator
+* _metainfo for unbound_ - is ignored by the schema generator
Examples:
[source]
@@ -6954,7 +6954,7 @@ module Mod {
==== Schema segments for type restrictions
-The compiler's `–ttcn2json` option also generates schema segments for type restrictions (subtyping constraints), even though these are ignored by the JSON encoder and decoder. Only restrictions of TTCN-3 types are converted to JSON schema format, ASN.1 type restrictions are ignored.
+The compiler's `-ttcn2json` option also generates schema segments for type restrictions (subtyping constraints), even though these are ignored by the JSON encoder and decoder. Only restrictions of TTCN-3 types are converted to JSON schema format, ASN.1 type restrictions are ignored.
The generated schema segments only contain basic JSON schema keywords, no extra keywords are needed.
@@ -7797,7 +7797,7 @@ with { erroneous (b) "value := MyInteger:1" }
Main features of negative testing in TITAN:
-* This feature is supported only by the Function Test runtime of TITAN; when doing negative testing this feature must be turned on using the *–R* switch to switch from the default Load Test runtime to the Function Test runtime
+* This feature is supported only by the Function Test runtime of TITAN; when doing negative testing this feature must be turned on using the *-R* switch to switch from the default Load Test runtime to the Function Test runtime
* Performance and functionality in case of positive testing is not affected by this feature
@@ -8229,7 +8229,7 @@ function func2() {
var integer x := 7;
@update(c_myrec) with {
erroneous(i) "value := x + 6";
- erroneous(b) "value := int2str(1 + f_sqr(x – 3)) & \"x\" ";
+ erroneous(b) "value := int2str(1 + f_sqr(x - 3)) & \"x\" ";
}
log(encvalue(c_myrec)); // output: {"i":13,"b":"17x"}
}
@@ -8628,9 +8628,9 @@ When a TTCN-3 project (with profiling enabled) finishes execution, a statistics
The profiler can be activated in the desired TTCN-3 modules with the compiler option `-z`, followed by a text file containing the list of TTCN-3 file names to be profiled separated by new line characters (this list can also contain `ttcnpp` files).
-The TTCN-3 makefile generator can set this option automatically with its own `–z` option (with the same file argument) or through the TPD file.
+The TTCN-3 makefile generator can set this option automatically with its own `-z` option (with the same file argument) or through the TPD file.
-When `–z` is set, the compiler generates extra code for profiling and code coverage in the code generated for these modules.
+When `-z` is set, the compiler generates extra code for profiling and code coverage in the code generated for these modules.
The compiler option `-L` must also be specified.
@@ -8718,7 +8718,7 @@ Here is an example of the sorted average times in the previously mentioned modul
The statistics file contains the following lists:
-* Number of code lines and functions – this list is an exception from the previously mentioned rules; this list contains one element per module and specifies the number of code lines and function in that module, ending with a line made of dashes and the total number of code lines and functions
+* Number of code lines and functions - this list is an exception from the previously mentioned rules; this list contains one element per module and specifies the number of code lines and function in that module, ending with a line made of dashes and the total number of code lines and functions
+
Example:
+
@@ -8734,12 +8734,12 @@ prof3.ttcn: 13 lines, 3 functions
Total: 36 lines, 10 functions
----
-* Raw data (4 lists) – one list containing both the total time and execution count for each code line and one list containing their average times, followed by one list with the total times and execution counts of functions and one list with their average times
-* Sorted total times (4 lists) – one list for code lines grouped by module and one (global) for the code lines in all modules, followed by the same for functions (these lists only contain the total execution time of each code line and function)
-* Sorted execution counts (4 lists) – same as the lists of total times
-* Sorted average times (4 lists) – same as the previous two
-* Top 10 total times, execution counts and average times (6 lists) – these contain the first 10 entries from every sorted global list (in the order mentioned in the previous three)
-* Unused code lines and functions (2 lists) – these don't contain any data, only the code line / function specification, they are grouped by module, first the unused lines, then the functions
+* Raw data (4 lists) - one list containing both the total time and execution count for each code line and one list containing their average times, followed by one list with the total times and execution counts of functions and one list with their average times
+* Sorted total times (4 lists) - one list for code lines grouped by module and one (global) for the code lines in all modules, followed by the same for functions (these lists only contain the total execution time of each code line and function)
+* Sorted execution counts (4 lists) - same as the lists of total times
+* Sorted average times (4 lists) - same as the previous two
+* Top 10 total times, execution counts and average times (6 lists) - these contain the first 10 entries from every sorted global list (in the order mentioned in the previous three)
+* Unused code lines and functions (2 lists) - these don't contain any data, only the code line / function specification, they are grouped by module, first the unused lines, then the functions
Any of these lists can be disabled in the configuration file (either one by one or grouped).
@@ -8802,7 +8802,7 @@ ttcn3_profmerge [-pc] [-o file] [-s file] [-f filter] db_file1 [db_file2 …]
or
[source]
-ttcn3_profmerge –v
+ttcn3_profmerge -v
The command line arguments are the input database files, these must always be listed after the switches, and there must be at least one of them.
diff --git a/usrguide/referenceguide/5-supported_asn1_constructs_and_limitations.adoc b/usrguide/referenceguide/5-supported_asn1_constructs_and_limitations.adoc
index 93eb5a2d31fa527069def255ff410e023d428e76..e1f47abc8c4cd9f744257d0e2c2028120fc12015 100644
--- a/usrguide/referenceguide/5-supported_asn1_constructs_and_limitations.adoc
+++ b/usrguide/referenceguide/5-supported_asn1_constructs_and_limitations.adoc
@@ -7,7 +7,7 @@ All kind of comments defined in X.680 clause 11.6 can be used (<<13-references.a
All tagging environment is supported: `IMPLICIT`, `EXPLICIT` and also `AUTOMATIC`.
-The type constraints are ignored. The BER (de)coding is not influenced by the constraints, except for the table constraints. For details, see section <<6-compiling_ttcn3_and_asn1_modules.adoc#using-component-relation-constraints-from-ttcn-3, Using Component Relation Constraints from TTCN–3>>.
+The type constraints are ignored. The BER (de)coding is not influenced by the constraints, except for the table constraints. For details, see section <<6-compiling_ttcn3_and_asn1_modules.adoc#using-component-relation-constraints-from-ttcn-3, Using Component Relation Constraints from TTCN-3>>.
Table 11 summarizes how the different ASN.1 types are supported.
diff --git a/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc b/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
index c6fb4fc4f4be1b76022146a61e058fe970355fbe..a58efd02c8f1ceaf41933c0e4eb1e60cc4ed4f2a 100644
--- a/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
+++ b/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
@@ -1,9 +1,9 @@
[[compiling-ttcn-3-and-asn-1-modules]]
-= Compiling TTCN–3 and ASN.1 Modules
+= Compiling TTCN-3 and ASN.1 Modules
:toc:
:table-number: 11
-You can translate your TTCN–3 and ASN.1 modules to {cpp} source code using the program compiler.
+You can translate your TTCN-3 and ASN.1 modules to {cpp} source code using the program compiler.
[[command-line-syntax]]
== Command Line Syntax
@@ -30,11 +30,11 @@ or
[source]
compiler --ttcn2json [ -jf ] … [ -T ] module.ttcn [ -A ] module.asn … [ - schema.json ]
-The compiler takes the name of files containing TTCN–3 and ASN.1 modules as arguments. The usual and recommended suffix is `.ttcn` for TTCN–3 and `.asn` for ASN.1 source files, but it is not stringentfootnote:[Other tool vendors may use .mp, .3mp or .asn1 suffixes as well.]. For TTCN–3 and ASN.1 modules, the names of the output files are the same as the name of the modules, except for the suffixes which are `.hh` and `.cc`.
+The compiler takes the name of files containing TTCN-3 and ASN.1 modules as arguments. The usual and recommended suffix is `.ttcn` for TTCN-3 and `.asn` for ASN.1 source files, but it is not stringentfootnote:[Other tool vendors may use .mp, .3mp or .asn1 suffixes as well.]. For TTCN-3 and ASN.1 modules, the names of the output files are the same as the name of the modules, except for the suffixes which are `.hh` and `.cc`.
NOTE: In the ASN.1 module names hyphens are replaced by underscore character.
-WARNING: If you have a modular test suite, you have to translate all modules of the test suite in one step, i.e. you have to specify all TTCN–3 and ASN.1 files in the argument list.
+WARNING: If you have a modular test suite, you have to translate all modules of the test suite in one step, i.e. you have to specify all TTCN-3 and ASN.1 files in the argument list.
The switches denoted by square brackets are optional. More than one option may be merged for abbreviation. For example, `-r` `-u` has exactly the same meaning as `-ru`.
@@ -70,7 +70,7 @@ This switch changes the way fields of ASN.1 SEQUENCE /SET types with DEFAULT val
+
[cols=",,",options="header",]
|===
-|Sending |Without –d |With –d
+|Sending |Without -d |With -d
|Explicit value |Send value |Send value
|Default value |Do not send (omit) |Send default value
|omit |N/A |Do not send (omit)
@@ -78,7 +78,7 @@ This switch changes the way fields of ASN.1 SEQUENCE /SET types with DEFAULT val
+
[cols=",,",options="header",]
|===
-|Receiving |Without –d |With –d
+|Receiving |Without -d |With -d
|Receive explicit value |TTCN sees value |TTCN sees value
|Receive default value |TTCN sees default value* |TTCN sees default value
|Omitted |TTCN sees default value** |TTCN sees `omit'
@@ -116,7 +116,7 @@ This option is used internally for pre-generating the mentioned {cpp} classes.
+
The compiler error/warning messages will contain the starting line number, and the starting column number if available. This option provides compatibility with the GNU compiler and many tools which are able to interpret its output (including Eclipse).
+
-If both `–g` and `–i` are specified, `-g` takes precedence.
+If both `-g` and `-i` are specified, `-g` takes precedence.
* `-h`
+
@@ -132,7 +132,7 @@ Enables the use of real-time testing features, i.e. the test system clock ('now'
* `-j`
+
-Disables the generation of JSON encoder/decoder routines for all TTCN–3 types.
+Disables the generation of JSON encoder/decoder routines for all TTCN-3 types.
* `-k`
+
@@ -164,7 +164,7 @@ Because of the `-T` flag the `Third.ttcn` will be treated as a TTCN-3 file, and
* `-l`
+
-Instructs the compiler to generate source file and line information (that is, #line directives) into the output code so that the error messages of the {cpp} compiler refer back to the lines of the original TTCN–3 input module. This makes finding the reason of {cpp} error messages easier. This option has effect only in the equivalent {cpp} code of TTCN–3 functions, test cases and control parts and this feature is not provided in other TTCN–3 definitions such as types, constants or templates.WARNING! This is an experimental feature and the {cpp} compiler may report misleading error messages that refer to totally wrong (e.g. non-existent) TTCN–3 line numbers. In these cases please turn off this flag, repeat the compilation and analyze the generated code manually. Without this flag, the compiler also inserts the source code information for the better understanding of {cpp} error messages, but only as {cpp} comments. This option has no impact on the run-time performance of the generated code. The compiler performs full semantic analysis on its entire input; it normally does not generate erroneous {cpp} code. So this option became obsolete and will be removed in future versions.
+Instructs the compiler to generate source file and line information (that is, #line directives) into the output code so that the error messages of the {cpp} compiler refer back to the lines of the original TTCN-3 input module. This makes finding the reason of {cpp} error messages easier. This option has effect only in the equivalent {cpp} code of TTCN-3 functions, test cases and control parts and this feature is not provided in other TTCN-3 definitions such as types, constants or templates.WARNING! This is an experimental feature and the {cpp} compiler may report misleading error messages that refer to totally wrong (e.g. non-existent) TTCN-3 line numbers. In these cases please turn off this flag, repeat the compilation and analyze the generated code manually. Without this flag, the compiler also inserts the source code information for the better understanding of {cpp} error messages, but only as {cpp} comments. This option has no impact on the run-time performance of the generated code. The compiler performs full semantic analysis on its entire input; it normally does not generate erroneous {cpp} code. So this option became obsolete and will be removed in future versions.
* `-L`
+
@@ -192,9 +192,9 @@ Disable the generation of OER encoding and decoding functions.
* `-p`
+
-Instructs the compiler only to parse the given TTCN–3 and ASN.1 modules. This will detect only the syntax errors in them because semantic checks are not performed. The presence of all imported modules is not necessary, thus, it is allowed (and recommended) to parse the modules one-by-one. All options that influence the code generation are silently ignored when used together with `-p`.
+Instructs the compiler only to parse the given TTCN-3 and ASN.1 modules. This will detect only the syntax errors in them because semantic checks are not performed. The presence of all imported modules is not necessary, thus, it is allowed (and recommended) to parse the modules one-by-one. All options that influence the code generation are silently ignored when used together with `-p`.
+
-NOTE: This option includes complete syntax checks for TTCN–3 modules, but in ASN.1 there are some special constructs (e.g. the user-defined syntaxes) that cannot be parsed without semantic analysis. So there is no guarantee that an ASN.1 module is free of syntax errors if it was analyzed with compiler using the -p flag.
+NOTE: This option includes complete syntax checks for TTCN-3 modules, but in ASN.1 there are some special constructs (e.g. the user-defined syntaxes) that cannot be parsed without semantic analysis. So there is no guarantee that an ASN.1 module is free of syntax errors if it was analyzed with compiler using the -p flag.
* `-P top level pdu …`
+
@@ -212,7 +212,7 @@ NOTE: Errors count is cumulative across all modules. Using this option may cause
* `-r`
+
-Disables the generation of RAW encoder/decoder routines for all TTCN–3 types.
+Disables the generation of RAW encoder/decoder routines for all TTCN-3 types.
* `-R`
+
@@ -220,11 +220,11 @@ Instructs the compiler to generate code for use with the function test runtime.
* `-s`
+
-Instructs the compiler to parse the given TTCN–3 and ASN.1 modules and perform semantic analysis on them, but not to generate {cpp} output.
+Instructs the compiler to parse the given TTCN-3 and ASN.1 modules and perform semantic analysis on them, but not to generate {cpp} output.
The list of given modules shall be complete so it is not allowed to import from a module that is not in the list.
All options that influence the code generation are silently ignored when used together with `-s`.
+
-NOTE: The TTCN–3 semantic analyzer of the compiler is still under development, thus, it is not capable of detecting every kind of semantic error.
+NOTE: The TTCN-3 semantic analyzer of the compiler is still under development, thus, it is not capable of detecting every kind of semantic error.
* `-S`
+
@@ -242,7 +242,7 @@ The `-S` option causes the compiler to output only the error (last line), withou
* `-t`
+
-Generates Test Port skeleton header and source files for all port types in the input TTCN–3 modules. Existing Test Port files will not be overwritten unless the -f option is used.
+Generates Test Port skeleton header and source files for all port types in the input TTCN-3 modules. Existing Test Port files will not be overwritten unless the -f option is used.
+
NOTE: In versions 1.1 and earlier this was the default behavior of the compiler, but if the existing Test Port source files were stored in a different directory, the generated new skeletons could be confusing.
@@ -308,7 +308,7 @@ Disables attribute checks for `encvalue` and `decvalue`. Must be used together w
* `-`
+
-The single dash character as command line argument has a special meaning: it controls the selective code generation. After the list of all TTCN–3 and ASN.1 modules a subset of these files can be given separated by a dash. This option instructs the compiler to parse all modules, perform the semantic analysis on the entire module hierarchy, but generate code only for those modules that are listed after the dash again. It is not allowed to specify a file name after the dash that was not present in the list before the dash. If the single dash is not present in the command line the compiler will generate code for all modules.
+The single dash character as command line argument has a special meaning: it controls the selective code generation. After the list of all TTCN-3 and ASN.1 modules a subset of these files can be given separated by a dash. This option instructs the compiler to parse all modules, perform the semantic analysis on the entire module hierarchy, but generate code only for those modules that are listed after the dash again. It is not allowed to specify a file name after the dash that was not present in the list before the dash. If the single dash is not present in the command line the compiler will generate code for all modules.
* `-ttcn2json`
+
@@ -328,7 +328,7 @@ Only types that have JSON encoding or decoding functions (or both) are validated
+
The single dash character as command line argument can be used to specify the name of the generated JSON schema file (it must be followed by exactly one argument, which is the file name). If it is not present, the schema file name is generated from the name of the first input file (the extension "`.ttcn`" or "`.asn`" is replaced by "`.json`", or "`.json`" is appended to the end of the file name if neither extension is present).
+
-The meaning of options is also included in the manual page of the compiler. If your TTCN–3 installation is correct, the command `man compiler` will show you this manual page. If not, check the `MANPATH` environment variable.
+The meaning of options is also included in the manual page of the compiler. If your TTCN-3 installation is correct, the command `man compiler` will show you this manual page. If not, check the `MANPATH` environment variable.
=== Makefile Generator
@@ -357,7 +357,7 @@ The switches denoted by square brackets are optional. More than one option may b
* `-a`
+
-The flag refers to files using absolute path names in the generated Makefile. Makefile uses by default relative path names to access files located outside the current working directory of the compiler. Files from the current working directory are always referenced using only the file name without any directory. The flag generates a Makefile that is capable of using pre-compiled {cpp} and object files from central directories in order to save disk space and compilation time. WARNING! This feature works only if the generated files of the central directory is kept up-to-date and all directories use exactly the same environment (platform, TTCN–3 Executor and {cpp} compiler version, etc.).
+The flag refers to files using absolute path names in the generated Makefile. Makefile uses by default relative path names to access files located outside the current working directory of the compiler. Files from the current working directory are always referenced using only the file name without any directory. The flag generates a Makefile that is capable of using pre-compiled {cpp} and object files from central directories in order to save disk space and compilation time. WARNING! This feature works only if the generated files of the central directory is kept up-to-date and all directories use exactly the same environment (platform, TTCN-3 Executor and {cpp} compiler version, etc.).
* `-c`
+
@@ -369,7 +369,7 @@ Dumps the data used for Makefile generation.
* `-e <ETS name>`
+
-Sets the name of the target binary program (i.e. the executable test suite) to <ETS name> in the generated Makefile. If this option is omitted, the name of the first TTCN–3 module will be used as default.
+Sets the name of the target binary program (i.e. the executable test suite) to <ETS name> in the generated Makefile. If this option is omitted, the name of the first TTCN-3 module will be used as default.
* `-E`
+
@@ -397,7 +397,7 @@ Enables the use of real-time testing features, i.e. the test system clock ('now'
* `-I path`
+
-Add path to the list of search paths which are used to search for referred TPD-s. `path` must be an absolute path and multiple `–I` switches can be used. The search paths are used when the `–t` switch is also present and a referred TPD project cannot be found at the location specified by `projectRelativeURI`. In this case the `makefilegen` tool tries to find the TPD file using the paths provided by `path`. If the `tpdName` attribute of a `ReferencedProject` element is present in the TPD, then the value of the `tpdName` attribute will be used as a TPD filename during the search. However if the `tpdName` attribute is missing, then the name attribute’s value with the `.tpd` suffix will be used. If there are multiple paths specified then the first `.tpd` file with the correct name found in the list of search paths is taken. See 6.1.3.4 for an example.
+Add path to the list of search paths which are used to search for referred TPD-s. `path` must be an absolute path and multiple `-I` switches can be used. The search paths are used when the `-t` switch is also present and a referred TPD project cannot be found at the location specified by `projectRelativeURI`. In this case the `makefilegen` tool tries to find the TPD file using the paths provided by `path`. If the `tpdName` attribute of a `ReferencedProject` element is present in the TPD, then the value of the `tpdName` attribute will be used as a TPD filename during the search. However if the `tpdName` attribute is missing, then the name attribute’s value with the `.tpd` suffix will be used. If there are multiple paths specified then the first `.tpd` file with the correct name found in the list of search paths is taken. See 6.1.3.4 for an example.
* `-J file`
+
@@ -413,7 +413,7 @@ Enable code coverage for TTCN-3 modules listed in `file`. `file` is an ASCII tex
* `-l`
+
-Enable dynamic linking. All files of the project will be compiled with `–fPIC` and for each (static) object, a new shared object will be created. Then, these shared objects will be linked to the final executable instead of the (static) objects. It can be used to speed up the linking phase, in the price of somewhat lower performance and increased memory usage. It’s recommended to use this flag only in the development phase of the project. Please note, that both the project’s working directory (which holds the TITAN generated `.so` files) and the directory of TITAN libraries, most probably `${TTCN3_DIR}/lib`, should be appended to the `LD_LIBRARY_PATH` environment variable. Otherwise, the dynamic linker (or loader) won’t be able to locate the shared objects required by the executable. This option is not supported on Windows (platform string `WIN32`).
+Enable dynamic linking. All files of the project will be compiled with `-fPIC` and for each (static) object, a new shared object will be created. Then, these shared objects will be linked to the final executable instead of the (static) objects. It can be used to speed up the linking phase, in the price of somewhat lower performance and increased memory usage. It’s recommended to use this flag only in the development phase of the project. Please note, that both the project’s working directory (which holds the TITAN generated `.so` files) and the directory of TITAN libraries, most probably `${TTCN3_DIR}/lib`, should be appended to the `LD_LIBRARY_PATH` environment variable. Otherwise, the dynamic linker (or loader) won’t be able to locate the shared objects required by the executable. This option is not supported on Windows (platform string `WIN32`).
* `-L`
+
@@ -445,7 +445,7 @@ Add file to the list of other files in the generated `Makefile` without analyzin
* `-p`
+
-Generates `Makefile` with TTCN–3 preprocessing. All the TTCN–3 source files with the suffix `.ttcnpp` will be preprocessed using the C preprocessor. For details see <<12-tips_&_troubleshooting.adoc#using-the-ttcn-3-preprocessing-functionality, Using the TTCN-3 Preprocessing Functionality>>.
+Generates `Makefile` with TTCN-3 preprocessing. All the TTCN-3 source files with the suffix `.ttcnpp` will be preprocessed using the C preprocessor. For details see <<12-tips_&_troubleshooting.adoc#using-the-ttcn-3-preprocessing-functionality, Using the TTCN-3 Preprocessing Functionality>>.
* `-R`
+
@@ -477,7 +477,7 @@ Enforces legacy behaviour of the "out" function parameters (the "out" parameter
* `-z file`
+
-Enables code coverage and profiling in the TTCN-3 files listed in the `file` argument. The TTCN-3 files in the list must be separated by new lines and must also appear among the makefile generator’s arguments (this switch is ignored if the –t option is present).
+Enables code coverage and profiling in the TTCN-3 files listed in the `file` argument. The TTCN-3 files in the list must be separated by new lines and must also appear among the makefile generator’s arguments (this switch is ignored if the -t option is present).
+
If any of the source (TTCN-3, ASN.1, user-written {cpp}) files does not exist or cannot be accessed, `ttcn3_makefilegen` exits with an error.
+
@@ -533,7 +533,7 @@ The following TPD related command line options are available:
* `-t filename.tpd [-b buildconfig]`
+
-Use the supplied Titan Project Descriptor file to generate the Makefile. Information about directories, files and certain options is extracted from the TPD file and used to generate the Makefile(s). Additional files can be specified on the command line. Options from the command line override any option specified in the TPD file. If hierarchical makefilegen is ordered (-Frcg or –FrcgWp) then the immediately referred projects will be generated according to the element <requiredConfiguration> of the ordered top level active configuration. This is applied recursively.
+Use the supplied Titan Project Descriptor file to generate the Makefile. Information about directories, files and certain options is extracted from the TPD file and used to generate the Makefile(s). Additional files can be specified on the command line. Options from the command line override any option specified in the TPD file. If hierarchical makefilegen is ordered (-Frcg or -FrcgWp) then the immediately referred projects will be generated according to the element <requiredConfiguration> of the ordered top level active configuration. This is applied recursively.
* `-b buildconfig`
+
@@ -581,7 +581,7 @@ Use the improved linking method. It generates a flexible hierarchy of static and
* `-H`
+
-Use hierarchical project generation. Use it with –Z option. It provides makefiles for generating hierarchical binaries without flattening the project hierarchy. make can be called in any working directory, the lower level projects will be handled properly. All project can be regarded as top level project. Execution time of make is higher than in case of applying –Z without –H. (The difference is 50-100% for top level modification, 0-10% for lower level modification.)
+Use hierarchical project generation. Use it with -Z option. It provides makefiles for generating hierarchical binaries without flattening the project hierarchy. make can be called in any working directory, the lower level projects will be handled properly. All project can be regarded as top level project. Execution time of make is higher than in case of applying -Z without -H. (The difference is 50-100% for top level modification, 0-10% for lower level modification.)
Examples:
@@ -853,9 +853,9 @@ If we execute the command: compiler `-U 4 My_Types.ttcn My_Functions.ttcn My_Con
* `My_Constants_part_4.cc` (contains approximately 0 effective characters)
[[the-compilation-process-for-ttcn-3-and-asn-1-modules]]
-== The Compilation Process for TTCN–3 and ASN.1 Modules
+== The Compilation Process for TTCN-3 and ASN.1 Modules
-Before analyzing the input modules the compiler applies some heuristics for each source file to determine whether it contains a TTCN–3 or ASN.1 module. These so-called pre-parsing algorithms consider only the first few words of the files so it can happen that the compiler is unable to recognize its input and stops immediately with an error message. This is the case, for example, if the beginning of the module is either erroneous or contains strange and misleading comments. In this case using the command-line options `-T` and `-A` you can bypass the pre-parsers and force to interpret the corresponding file as a TTCN–3 or ASN.1 module, respectively.
+Before analyzing the input modules the compiler applies some heuristics for each source file to determine whether it contains a TTCN-3 or ASN.1 module. These so-called pre-parsing algorithms consider only the first few words of the files so it can happen that the compiler is unable to recognize its input and stops immediately with an error message. This is the case, for example, if the beginning of the module is either erroneous or contains strange and misleading comments. In this case using the command-line options `-T` and `-A` you can bypass the pre-parsers and force to interpret the corresponding file as a TTCN-3 or ASN.1 module, respectively.
During its run, the compiler reports its activities on its standard error stream like the following. The level of detail for these messages can be controlled with the flag `-V`.
[source]
@@ -871,11 +871,11 @@ Notify: File 'MyAsnModule.cc' updated.
Notify: 4 files updated.
----
-First, the compiler reads the TTCN–3 and ASN.1 input files and performs syntax check according to the BNF of TTCN–3 <<13-references.adoc#_1, [1]>> (including the additions of <<13-references.adoc#_3, [3]>>) or ASN.1 <<13-references.adoc#_4, [4]>>, <<13-references.adoc#_7, [7]>>, <<13-references.adoc#_8, [8]>>, <<13-references.adoc#_9, [9]>>. The syntax errors are reported with the appropriate line number. Whenever it is possible, the compiler tries to recover from syntax errors and continue the analysis in order to detect further errors.
+First, the compiler reads the TTCN-3 and ASN.1 input files and performs syntax check according to the BNF of TTCN-3 <<13-references.adoc#_1, [1]>> (including the additions of <<13-references.adoc#_3, [3]>>) or ASN.1 <<13-references.adoc#_4, [4]>>, <<13-references.adoc#_7, [7]>>, <<13-references.adoc#_8, [8]>>, <<13-references.adoc#_9, [9]>>. The syntax errors are reported with the appropriate line number. Whenever it is possible, the compiler tries to recover from syntax errors and continue the analysis in order to detect further errors.
NOTE: Error recovery is not always successful and it might result in additional undesired error messages when the parser gets out of synchronization. Therefore it is recommended to study the first lines on the compiler’s error listings because the error messages at the end are not always relevant.
-After the syntax check the compiler performs semantic analysis on TTCN–3 /ASN.1 module(s) and verifies whether the various definitions and language elements are used in the appropriate way according to the static semantics of TTCN–3 and ASN.1 languages. In addition to error messages the compiler reports a warning when the corresponding definition is correct, but it might have unwanted effects.
+After the syntax check the compiler performs semantic analysis on TTCN-3 /ASN.1 module(s) and verifies whether the various definitions and language elements are used in the appropriate way according to the static semantics of TTCN-3 and ASN.1 languages. In addition to error messages the compiler reports a warning when the corresponding definition is correct, but it might have unwanted effects.
If both syntax and semantic checks were successful, the compiler generates a {cpp} header and source file that contains the translated module. If the name of the input module is `MyModule` (i.e. it begins with module `MyModule`), the name of the generated header and source file will be `MyModule.hh` and `MyModule.cc`, respectively. Note that the name of the output file does NOT depend on the name of input file. In ASN.1 module names the hyphens are converted to underscore characters (e.g. the {cpp} code for `My-Asn-Module` will be placed into `My_Asn_Module.hh` and `My_Asn_Module.cc`).
@@ -883,14 +883,14 @@ By default, the compiler generates the {cpp} code for all input modules. This ca
This sophisticated command line syntax is necessary because in general case it is impossible to perform the semantic analysis on a subset of the modules because those may import from modules outside the list. Moreover, to avoid undesirable side-effects of the code optimization techniques implemented in the compiler (e.g. type and value folding) the {cpp} code is generated not only for the modified modules, but for all modules that import definitions (either directly or indirectly) from the modified ones.
-When the compiler translates an ASN.1 module, the different ASN.1 types are mapped to TTCN–3 types as described in the table below.
+When the compiler translates an ASN.1 module, the different ASN.1 types are mapped to TTCN-3 types as described in the table below.
-.Mapping of ASN.1 types to TTCN–3 types
+.Mapping of ASN.1 types to TTCN-3 types
[cols=",",options="header",]
|===
-|ASN.1 |TTCN–3
+|ASN.1 |TTCN-3
|Simple types |
-|NULL |– *
+|NULL |- *
|BOOLEAN |boolean
|INTEGER |integer
|ENUMERATED |enumerated
@@ -910,7 +910,7 @@ When the compiler translates an ASN.1 module, the different ASN.1 types are mapp
|SET OF |set of
|===
-\* there is no corresponding TTCN–3 type +
+\* there is no corresponding TTCN-3 type +
†IA5String, NumericString, PrintableString, VisibleString (ISO646String) +
‡ GeneralString, GraphicString, TeletexString (T61String), VideotexString +
§ BMPString, UniversalString, UTF8String +
@@ -1015,9 +1015,9 @@ Illegal-type ::= SET {
The problem is that the (BER) decoder of a version 1 system cannot attribute an unknown element (received from a version 2 system) unambiguously to a specific insertion point.
[[using-component-relation-constraints-from-ttcn-3]]
-== Using Component Relation Constraints from TTCN–3
+== Using Component Relation Constraints from TTCN-3
-To handle constructs defined in X.681, X.682 and X.683 is not easy from TTCN–3. There is an ETSI technical reportfootnote:[TR 101 295] which describes how to transform these constructs to equivalent X.680 constructs. The clause 4.4 of this document is about transforming information objects.
+To handle constructs defined in X.681, X.682 and X.683 is not easy from TTCN-3. There is an ETSI technical reportfootnote:[TR 101 295] which describes how to transform these constructs to equivalent X.680 constructs. The clause 4.4 of this document is about transforming information objects.
"The transformation rules presented in this clause cannot reproduce the full semantics of the information objects they replace. The transformation rules cannot preserve component relation constraints. These constraints provide the ability to constrain a type or value with reference to a different field within an information object set."
diff --git a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
index affe561c7e99cc9f341ee5c41331ecdc3a6da10e..afb2512bfd3b1e3216f898e190486626c92b687f 100644
--- a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
+++ b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
@@ -8,20 +8,20 @@ Each section begins with a section name within square brackets. Different sectio
The configuration file can contain any white space characters. There are three ways to put comments in the file: you can use the C comment delimiters (i.e. /* and */). Additionally, characters beginning with # or // are treated as comments until the end of line.
-Character string values shall be given between quotation marks. The non-printable characters as well as the quotation mark character within string values must be escaped using TTCN–3 or C escape sequences or quadruple notation. All kinds of escape sequences that are available in TTCN–3 and C languages (including octal and hexadecimal notation) are recognized.
+Character string values shall be given between quotation marks. The non-printable characters as well as the quotation mark character within string values must be escaped using TTCN-3 or C escape sequences or quadruple notation. All kinds of escape sequences that are available in TTCN-3 and C languages (including octal and hexadecimal notation) are recognized.
All sections are optional, thus an empty file is also a valid (but meaningless) configuration file. The sections are processed in the given order. In case of duplicated sections, all sections will be processed and no warnings will be issued.
In the following we present all possible sections of the configuration file. The majority of sections are applicable in both single and parallel modes with identical meaning. However, some sections or settings in a section are applicable either in single or parallel mode only.
-The indication (Parallel mode) following the section title signals that the concerned section is processed in parallel operation mode only. Irrelevant sections or options are ignored in each mode and a warning message is displayed during configuration file processing. For details on running TITAN TTCN–3 test suites in either single or parallel mode using see the TITAN TTCN–3 User Guide (see <<13-references.adoc#_13, [13]>>).
+The indication (Parallel mode) following the section title signals that the concerned section is processed in parallel operation mode only. Irrelevant sections or options are ignored in each mode and a warning message is displayed during configuration file processing. For details on running TITAN TTCN-3 test suites in either single or parallel mode using see the TITAN TTCN-3 User Guide (see <<13-references.adoc#_13, [13]>>).
The component name defined by the `create` operation (see <<4-ttcn3_language_extensions.adoc#parameters-of-create-operation, here>>) can contain any characters. This component name can be used without quoted marks but it shall be used with quoted marks (i.e as quoted string) if it contains extra characters e.g. space (" "), hyphen ("-") or dot ("."). See also the examples of this chapter in sections <<module-parameters, [MODULE_PARAMETERS]>> and <<testport-parameters, [TESTPORT_PARAMETERS]>>.
[[module-parameters]]
== [MODULE_PARAMETERS]
-This section may contain the values of any parameters that are defined in your TTCN–3 modules.
+This section may contain the values of any parameters that are defined in your TTCN-3 modules.
The parameters shall be specified after each other in any order. Each parameter must be given in the following order: module name (optional) <<13-references.adoc#_24, [24]>>, parameter name, field names (in case of records, sets or unions; optional) or array indexes (in case of arrays, records of or sets of; optional), assignment or concatenation operator (that is, the characters := or &=) and parameter value. An optional terminator semicolon may be used after each parameter value. The concatenation operator can be applied to list types (record of, set of). In this case only the value list notation can be used.
@@ -93,23 +93,23 @@ The parameter value can be one of the following:
* Integer value. A number in decimal notation or an expression composed of numbers using the basic arithmetic operations to allow more flexibility with macro substitution.
* Floating point value. A floating point number in decimal dot notation or exponential notation or an arithmetic expression composed of such values.
-* Bitstring value (in the notation of TTCN–3). String fragments can be concatenated to allow more flexible macro substitution.
-* Hexstring value (in the notation of TTCN–3). String fragments can be concatenated to allow more flexible macro substitution.
-* Octetstring value (in the notation of TTCN–3). String fragments can be concatenated to allow more flexible macro substitution.
+* Bitstring value (in the notation of TTCN-3). String fragments can be concatenated to allow more flexible macro substitution.
+* Hexstring value (in the notation of TTCN-3). String fragments can be concatenated to allow more flexible macro substitution.
+* Octetstring value (in the notation of TTCN-3). String fragments can be concatenated to allow more flexible macro substitution.
* Charstring value (between quotation marks; escape sequences are allowed). String fragments can be concatenated to allow more flexible macro substitution.
-* Universal charstring value (sequence of concatenated fragments; each fragment can be either a printable string within quotation marks or a quadruple in TTCN–3 notation).
+* Universal charstring value (sequence of concatenated fragments; each fragment can be either a printable string within quotation marks or a quadruple in TTCN-3 notation).
* Boolean value (`true` or `false`).
-* Object identifier (`objid`) value (in the notation of TTCN–3). Only `NumberForm` or `NameAndNumberForm` notations are allowed.
+* Object identifier (`objid`) value (in the notation of TTCN-3). Only `NumberForm` or `NameAndNumberForm` notations are allowed.
* Verdict value (`none`, `pass`, `inconc`, `fail` or `error`).
* Enumerated value (the symbolic value, i.e. an identifier). Numeric values are not allowed.
* Omit value (i.e.`Â omit`). Valid for optional record or set fields only.
-* `null` value for TTCN–3 component and default references.
+* `null` value for TTCN-3 component and default references.
* `NULL` value for the ASN.1 `NULL` type.
* "?" value: AnyValue for matching
* "*" value: AnyValueOrNone for matching
* IntegerRange/FloatRange/StringRange: matching an integer/float/charstring range
* Pattern for pattern matching in charstring and universal charstring
-* Bit/Hex/Octet –string matching mechanism which are bit/hex/octet strings that contain "?" and "*" for matching
+* Bit/Hex/Octet -string matching mechanism which are bit/hex/octet strings that contain "?" and "*" for matching
* "mtc" and "system" values for component references
* Compound value with assignment notation. One or more fields (separated by commas) with field names within brackets for types `record` and `set`.
* Compound value with value list notation. Comma separated list of values between brackets for types `record of`, `set of` and `array`.
@@ -227,7 +227,7 @@ The default logging is the statically loaded built in logging.
The dynamically loaded logging can be the built in LegacyLogger, the plugins shipped with TITAN (see <<dynamically-loaded-logger-plugins-shipped-with-titan, here>>) or user created dynamically linked plugins (for advanced users, see chapter 3 in <<13-references.adoc#_16, [16]>>.
-NOTE: *When using dynamically loaded logger plugins it is very important to use the dynamic runtime library of TITAN, this can be done by using the –l switch when generating the makefile.*
+NOTE: *When using dynamically loaded logger plugins it is very important to use the dynamic runtime library of TITAN, this can be done by using the -l switch when generating the makefile.*
The desired logger plugins need to be set in the `LoggerPlugins` option. The `LoggerPlugins` option takes a non-empty, comma separated list of logger plugin settings. These settings can be specified in the following ways:
@@ -318,7 +318,7 @@ LoggerPlugins := { JUnitLogger := "libjunitlogger" }
hello.control
----
-The makefile was generated by the command `makefilegen –fl hello.ttcn`.
+The makefile was generated by the command `makefilegen -fl hello.ttcn`.
The executable was executed by the command `ttcn3_start hello cfg.cfg`.
@@ -353,8 +353,8 @@ Each testcase starts with two xml style comments which is followed by a <testcas
Each testcase starts with the following two xml comments:
-* `<!– Testcase "name of the testcase" started –>`
-* `<!– Testcase "name of the testcase" finished in "execution time is seconds", verdict:"verdict" –>`
+* `<!- Testcase "name of the testcase" started ->`
+* `<!- Testcase "name of the testcase" finished in "execution time is seconds", verdict:"verdict" ->`
This is followed by a <testcase> tag.
@@ -378,7 +378,7 @@ Has the following element content with the following attribute:
<failure type=`fail-verdict'>
-The <failure> tag can have several of the following text contents – each in a separate line (see results log example above):
+The <failure> tag can have several of the following text contents - each in a separate line (see results log example above):
* control part
* testcase
@@ -389,9 +389,9 @@ The <failure> tag can have several of the following text contents – each in a
Each line contains `"filename:linenumber identifier definition"`, where each of the items mean the following:
-* filename:linenumber – the file and the line where the test failed
-* identifier – the identifier depending on the definition, e.g. the classname in case of "control part" or the name of the test in case of "testcase"
-* definition – see the list in <failure> tag text content
+* filename:linenumber - the file and the line where the test failed
+* identifier - the identifier depending on the definition, e.g. the classname in case of "control part" or the name of the test in case of "testcase"
+* definition - see the list in <failure> tag text content
This is a simple stacktrace of the failure.
@@ -483,15 +483,15 @@ LoggerPlugins := { JUnitLogger := "libjunitlogger2" }
+
New attributes:
+
-tests – number of all testcases executed
+tests - number of all testcases executed
+
-failures – number of testcases whose final verdict is fail
+failures - number of testcases whose final verdict is fail
+
-errors – number of testcases that encountered an error
+errors - number of testcases that encountered an error
+
-skipped – number of testcases with a none verdict
+skipped - number of testcases with a none verdict
+
-time – the time in seconds from the start of the tests until all the testcases executed.
+time - the time in seconds from the start of the tests until all the testcases executed.
+
* XML comments are not added to the output.
* XSD:
@@ -620,7 +620,7 @@ To use the LTTng-UST logger plugin:
. Make sure LTTng (2.7 or greater) is installed (the LTTng-tools and LTTng-UST components are required).
. Add the following line to your runtime configuration file:LoggerPlugins := { LTTngUSTLogger := "liblttng-ust-logger" }
. Create an LTTng tracing session:lttng create
-. Enable TITAN events:lttng enable-event –userspace titan_core:'*'
+. Enable TITAN events:lttng enable-event -userspace titan_core:'*'
. Start tracing:lttng start
. Run your test script.
. When you are done, stop tracing:lttng stop
@@ -639,8 +639,8 @@ The table below contains the list of available metacharacters in alphabetical or
[cols="m,",options="header",]
|===
|Meta-character |Substituted with . . .
-|%c |the name of the TTCN–3 test case that the PTC belongs to.
-|%e |the name of the TTCN–3 executable. The .exe suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
+|%c |the name of the TTCN-3 test case that the PTC belongs to.
+|%e |the name of the TTCN-3 executable. The .exe suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
|%h |the name of the computer returned by the gethostname(2) system call. This usually does not include the domain name.
|%i |the sequence number of the log fragment.
|%l |the login name of the current user. If the login name cannot be determined (e.g. the current UNIX user ID has no associated login name) an empty string is returned.
@@ -651,7 +651,7 @@ The table below contains the list of available metacharacters in alphabetical or
| %p | the process ID (`pid`) of the UNIX process that implements the current test component. The `pid` is written in decimal notation.
| %r | the component reference or component identifier. On PTCs it is the component reference (an integer number greater or equal to 3) in decimal notation. On the Main Test Component, Host Controller or in single mode the strings `mtc`, `hc` or `single` are substituted, respectively.
| %s | the default suffix for the log files without the leading dot. Now it always results in string log, but future versions may support log file compression. In this case the suffix will depend on the chosen compression method.
-| %t | the TTCN–3 component type. Note: The MTC and HC have no dedicated component type since they can implement several component types in different test cases.
+| %t | the TTCN-3 component type. Note: The MTC and HC have no dedicated component type since they can implement several component types in different test cases.
| %% | a single % character.
|===
@@ -717,7 +717,7 @@ It is also possible to apply the filtering on selected logger plugins of a compo
[cols=",",options="header",]
|===
|Logging categories |Symbolic constantfootnote:[In order to be compatible with older configuration files, the following symbolic constants are also recognized: TTCN_ERROR, TTCN_WARNING, TTCN_PORTEVENT, TTCN_TIMEROP, TTCN_VERDICTOP, TTCN_DEFAULTOP, TTCN_TESTCASE, TTCN_ACTION, TTCN_USER, TTCN_FUNCTION, TTCN_STATISTICS, TTCN_PARALLEL, TTCN_EXECUTOR, TTCN_MATCHING and TTCN_DEBUG. These constants have the same meaning as their counterparts without the prefix TTCN_.]
-|TTCN–3 action(…) statements(No subcategory is implemented) |`ACTION`
+|TTCN-3 action(…) statements(No subcategory is implemented) |`ACTION`
|Debug messages in Test Ports and external functions(For subcategories see Table 15) |`DEBUG`
|Default operations (`activate`, `deactivate`, `return`)(For subcategories see Table 16) |`DEFAULTOP`
|Dynamic test case errors (e.g. snapshot matching failures)(No subcategory is implemented) |`ERROR`
@@ -895,24 +895,24 @@ In both single and parallel modes some log events are created before processing
=== `SourceInfoFormat`
-Option `SourceInfoFormat` controls the appearance of the location information for the test events. The location information refers to a position in the TTCN–3 source code. It consists of the name of the TTCN–3 file and the line number separated by a colon character (:). Optionally, it may contain the name of the TTCN–3 entity (function, testcase, etc.) in parentheses that the source line belongs to. See also the option <<LogEntityName, `LogEntityName`>> below.
+Option `SourceInfoFormat` controls the appearance of the location information for the test events. The location information refers to a position in the TTCN-3 source code. It consists of the name of the TTCN-3 file and the line number separated by a colon character (:). Optionally, it may contain the name of the TTCN-3 entity (function, testcase, etc.) in parentheses that the source line belongs to. See also the option <<LogEntityName, `LogEntityName`>> below.
-The option can take one of the three possible values: `None`, `Single` and `Stack`. In case of `Single`, the location information of the TTCN–3 statement is logged that is currently being executed. When `Stack` is used the entire TTCN–3 call stack is logged. The logged information starts from the outermost control part or testcase and ends with the innermost TTCN–3 statement. An arrow (that is, the character sequence ->) is used as separator between the stack frames. The value `None` disables the printing of location information. The default value for `SourceInfoFormat` is `None`.
+The option can take one of the three possible values: `None`, `Single` and `Stack`. In case of `Single`, the location information of the TTCN-3 statement is logged that is currently being executed. When `Stack` is used the entire TTCN-3 call stack is logged. The logged information starts from the outermost control part or testcase and ends with the innermost TTCN-3 statement. An arrow (that is, the character sequence ->) is used as separator between the stack frames. The value `None` disables the printing of location information. The default value for `SourceInfoFormat` is `None`.
The location information is placed in each line of the log file between the event type or timestamp and the textual description of the event.
-This option works only if the command line option `–L` is passed to the compiler (see <<6-compiling_ttcn3_and_asn1_modules.adoc#command-line-syntax, here>>). This feature is useful for debugging new TTCN–3 code or for understanding the traces of complex control constructs. If the location information is not generated into the {cpp} code the executable tests run faster, which can be more important when doing performance tests.
+This option works only if the command line option `-L` is passed to the compiler (see <<6-compiling_ttcn3_and_asn1_modules.adoc#command-line-syntax, here>>). This feature is useful for debugging new TTCN-3 code or for understanding the traces of complex control constructs. If the location information is not generated into the {cpp} code the executable tests run faster, which can be more important when doing performance tests.
-NOTE: The reception of messages or procedure calls can only occur while the run-time environment is taking a new snapshot. A new snapshot is taken when the testcomponent is evaluating a stand-alone receiving operation, an `alt` construct or a standalone `altstep` invocation. Thus, the location information of the incoming messages or calls points to the first line of the above statements. The log event belonging to a TTCN–3 operation can be the extraction of a message from the port queue and not the reception of an incoming message.
+NOTE: The reception of messages or procedure calls can only occur while the run-time environment is taking a new snapshot. A new snapshot is taken when the testcomponent is evaluating a stand-alone receiving operation, an `alt` construct or a standalone `altstep` invocation. Thus, the location information of the incoming messages or calls points to the first line of the above statements. The log event belonging to a TTCN-3 operation can be the extraction of a message from the port queue and not the reception of an incoming message.
-If the event has no associated line in the TTCN–3 source code (e.g. because it belongs to test environment startup or termination) and `SourceInfoFormat` is set to either `Single` or `Stack`, a single dash character `(-)` is printed into the log instead of the location information. This makes the automated processing of log files easier.
+If the event has no associated line in the TTCN-3 source code (e.g. because it belongs to test environment startup or termination) and `SourceInfoFormat` is set to either `Single` or `Stack`, a single dash character `(-)` is printed into the log instead of the location information. This makes the automated processing of log files easier.
The obsolete option `LogSourceInfo` is also accepted for backward compatibility with earlier versions. Setting `LogSourceInfo` `:= Yes` is equivalent to `SourceInfoFormat` `:= Single`, and similarly `LogSourceInfo := No` means `SourceInfoFormat := None`.
[[LogEntityName]]
=== `LogEntityName`
-Option `LogEntityName` controls whether the name of the corresponding TTCN–3 entity (`function`, `testcase`, `altstep, control` part, etc.) shall be included in the location information. If this option is set to `Yes`, the file name and line number is followed by the name of the TTCN–3 entity within parentheses. The default value is `No`. The option has no effect if `SourceInfoFormat` is set to `None`.
+Option `LogEntityName` controls whether the name of the corresponding TTCN-3 entity (`function`, `testcase`, `altstep, control` part, etc.) shall be included in the location information. If this option is set to `Yes`, the file name and line number is followed by the name of the TTCN-3 entity within parentheses. The default value is `No`. The option has no effect if `SourceInfoFormat` is set to `None`.
=== `LogFileSize`
@@ -1145,7 +1145,7 @@ LogEventTypes := Yes
In this section you can specify parameters that are passed to Test Ports. Each parameter definition consists of a component name, a port name, a parameter name and a parameter value. The component name can be either an identifier that is assigned to the component in the `create` operation (see <<4-ttcn3_language_extensions.adoc#visibility-modifiers, here>>) or an integer value, which is interpreted as component reference[31]. The port and parameter names are identifiers while the parameter value must be always a `charstring` (with quotation marks). Instead of component name or port name (or both of them) the asterisk (*) sign can be used, which means "all components" or "all ports of the component".
-If the keyword `system` is used as a component identifier, the parameter is passed to all ports of all components that are mapped to the given port of the test system interface. In this case the port identifier refers to the port of the test system and not the port of a TTCN–3 test component. These parameters are passed to the appropriate Test Port during the execution of map operations because the future mappings are not known at test component initialization. The asterisk ("*") sign can also be used as port name with the component identifier system. This wildcard means, of course, all ports of the Test System Interface (that is, the parameter will be passed during all `map` operations).
+If the keyword `system` is used as a component identifier, the parameter is passed to all ports of all components that are mapped to the given port of the test system interface. In this case the port identifier refers to the port of the test system and not the port of a TTCN-3 test component. These parameters are passed to the appropriate Test Port during the execution of map operations because the future mappings are not known at test component initialization. The asterisk ("*") sign can also be used as port name with the component identifier system. This wildcard means, of course, all ports of the Test System Interface (that is, the parameter will be passed during all `map` operations).
The names and meaning of Test Port parameters depend on the Test Port that you are using; for this information please consult the user documentation of your Test Port. It is the Test Port writer’s responsibility to process the parameter names and values. For the details of Test Port API see the section "Parameter setting function" in <<13-references.adoc#_16, [16]>>.
@@ -1178,7 +1178,7 @@ system.MySystemInterface2.RemoteIPAddress := "10.1.1.2"
In this section you can create macro definitions that can be used in other configuration file sections except `[INCLUDE]`. This way if the same value must be given several times in the configuration file, you can make a definition for it and only refer to the definition later on. In case of a change, you wouldn’t need to change the values all over the configuration file, but only in the definition.
-This section may contain zero, one or more macro definitions (assignments). Each macro definition consists of a macro identifier, which shall be a TTCN–3 identifier, an assignment operator and the macro value. The macro value is either a simple or a structured value (see the BNF below).
+This section may contain zero, one or more macro definitions (assignments). Each macro definition consists of a macro identifier, which shall be a TTCN-3 identifier, an assignment operator and the macro value. The macro value is either a simple or a structured value (see the BNF below).
The simple macro value is a sequence of one or more literal values and macro references. The elements of the sequence must not be separated by anything, whitespaces or comments are not allowed.
@@ -1237,7 +1237,7 @@ The reference with this modifier has the same result as a simple reference.
* `binaryoctet` +
Transforms the value of the macro into an octetstring value so that the octets of the resulting string will contain the ASCII character code of the corresponding character from the macro value. The macro value to be substituted may contain any kind of character.
* `identifier` +
-Transforms the value of the macro into a TTCN–3 identifier. This modifier is useful, for instance, for specifying values of enumerated types in section [`MODULE_PARAMETERS`]. The macro value shall contain a valid TTCN–3 identifier. Leading and trailing whitespace characters are not allowed in the macro value.
+Transforms the value of the macro into a TTCN-3 identifier. This modifier is useful, for instance, for specifying values of enumerated types in section [`MODULE_PARAMETERS`]. The macro value shall contain a valid TTCN-3 identifier. Leading and trailing whitespace characters are not allowed in the macro value.
* `hostname` +
Transforms the value of the macro into a host name, DNS name or IPv4 or IPv6 address. The modifier can be used in sections [`GROUPS`], [`COMPONENTS`] and [`MAIN_CONTROLLER`]. The value to be substituted shall contain a valid host name, DNS name or IP address formed from alphanumerical, dash (-), underscore (_), dot (.), colon(:) or percentage (%) characters. Leading and trailing whitespace is not allowed.
====
@@ -1429,7 +1429,7 @@ EndControlPart := ""
=== Example: Running `tcpdump` during test execution
-In case of testing IP based protocols it might be useful to monitor the network during TTCN–3 test execution. The following shell scripts show an example how to start the program `tcpdump` in the background at the beginning of every test case and how to terminate it when a test case is finished.
+In case of testing IP based protocols it might be useful to monitor the network during TTCN-3 test execution. The following shell scripts show an example how to start the program `tcpdump` in the background at the beginning of every test case and how to terminate it when a test case is finished.
When `tcpdump` is running, its `pid` is stored in the file `/etc/tcpdump.pid` to inform the stopping script which process to kill. Of course, the command line options for tcpdump may be changed to fit your needs. The output of `tcpdump` is saved in the file `<testcase name>.dump` in the working directory of the executable test program, which is useful when `repgen` is used after test execution.
@@ -1474,9 +1474,9 @@ fi
In this section you have to specify what parts of your test suite you want to execute. In single mode the configuration file is useless without this section. The section [`EXECUTE`] is optional in parallel mode. If it is missing, You shall start testcases manually from command line with the command `smtc` `[module name[.control|.testcase name|.*]]` see UG <<13-references.adoc#_17, [17]>> 4.4.2.1. In this case a parameter after smtc is mandatory. Don’t omit this section in case of using `ttcn3_start`, otherwise no testcase will be executed.
-You can start TTCN–3 module control parts and test cases individually. There is one limitation: only those test cases having no parameters, or only parameters with default values, can be executed from this section. Other test cases can be started from the module control part with proper actual parameters.
+You can start TTCN-3 module control parts and test cases individually. There is one limitation: only those test cases having no parameters, or only parameters with default values, can be executed from this section. Other test cases can be started from the module control part with proper actual parameters.
-In this section, a single identifier (or an identifier followed by the optional suffix `.control`) means the control part of that TTCN–3 module. Test case names shall be preceded by the name of module that they can be found in and a dot character. You can use the character asterisk (*) instead of test case name, which means the execution of all test cases of the corresponding module in the same order as they are defined in the TTCN–3 source code.
+In this section, a single identifier (or an identifier followed by the optional suffix `.control`) means the control part of that TTCN-3 module. Test case names shall be preceded by the name of module that they can be found in and a dot character. You can use the character asterisk (*) instead of test case name, which means the execution of all test cases of the corresponding module in the same order as they are defined in the TTCN-3 source code.
The control parts and test cases are executed in the same order as you specified them in this section. If you define the same module or test case name more than once, that control part or test case will be executed, of course, many times.
@@ -1511,7 +1511,7 @@ This section contains any number of group specifications in the following form:
Groups may overlap, that is, the same hosts can belong to several groups. Group references, however, cannot appear on the right side. It is worth mentioning that group names are case sensitive.
-NOTE: The groups defined in this section have nothing to do with TTCN–3 group of definitions construct!
+NOTE: The groups defined in this section have nothing to do with TTCN-3 group of definitions construct!
[[the-bnf-specification-of-this-section-0]]
=== The BNF Specification of this Section
@@ -1543,7 +1543,7 @@ The rules are described in form of assignments. The left side contains a compone
Each component type or component name can appear in at most one rule. The asterisk (*) stands for all component identifiers that do not appear in any rule. The asterisk can show in a single rule only.
-When a TTCN–3 parallel test component is being created it is the responsibility of the MC to choose a suitable and availablefootnote:[Only those hosts participate in the component distribution algorithm that have an active HC, which has been started by the user. MC ignores all unavailable group members silently and will not start the HC on them.] host for it. First a subset of available hosts, the set of so-called candidates, is determined based on the component distribution rules. The MC implements a load balancing algorithm so that the location of the component will be the candidate with the smallest load, that is, the least number of active TTCN–3 test componentsfootnote:[This term of load has no direct relation to the load average calculated by UNIX kernels.]. Once a component is assigned to a host it, cannot be moved to another one later during its life.
+When a TTCN-3 parallel test component is being created it is the responsibility of the MC to choose a suitable and availablefootnote:[Only those hosts participate in the component distribution algorithm that have an active HC, which has been started by the user. MC ignores all unavailable group members silently and will not start the HC on them.] host for it. First a subset of available hosts, the set of so-called candidates, is determined based on the component distribution rules. The MC implements a load balancing algorithm so that the location of the component will be the candidate with the smallest load, that is, the least number of active TTCN-3 test componentsfootnote:[This term of load has no direct relation to the load average calculated by UNIX kernels.]. Once a component is assigned to a host it, cannot be moved to another one later during its life.
If a newly created PTC matches more than one rule (because both its component type and name is found in the section) all available members of both assigned groups are considered to be candidates.
@@ -1582,7 +1582,7 @@ The value of option `TCPPort` is an integer number between 0 and 65535. The reco
The optional variable `NumHCs` provides support for automated (batch) execution of distributed tests. When present, the MC will not give a command prompt, but wait for `NumHCs` HCs to connect. When the specified number of HCs are connected, the MC automatically creates MTC and executes all items of the section <<execute, [`EXECUTE`]>>. When finished, the MTC is terminated and the MC quits automatically. If `NumHCs` was omitted then the MC shall be controlled interactively, that is, you have to issue the commands `cmtc` and `smtc` yourself (see also sections 12.3, 12.3.1 of the TITAN User Guide <<13-references.adoc#_13, [13]>>).
-The `KillTimer` option tells the MC to wait some seconds for a busy test component (MTC or PTC) to terminate when it was requested to stopfootnote:[The MTC can be terminated from the MC’s user interface or from a PTC by executing the mtc.stop operation. The termination of a PTC can be requested either explicitly (using a TTCN–3 component stop or kill operation) or implicitly (at the end of test case).]. The MC in co-operation with the local HC kills the UNIX process if the component did not terminate properly before `KillTimer` expiry. The purpose of this function is to prevent the test system from deadlocks.
+The `KillTimer` option tells the MC to wait some seconds for a busy test component (MTC or PTC) to terminate when it was requested to stopfootnote:[The MTC can be terminated from the MC’s user interface or from a PTC by executing the mtc.stop operation. The termination of a PTC can be requested either explicitly (using a TTCN-3 component stop or kill operation) or implicitly (at the end of test case).]. The MC in co-operation with the local HC kills the UNIX process if the component did not terminate properly before `KillTimer` expiry. The purpose of this function is to prevent the test system from deadlocks.
NOTE: When the UNIX process of MTC is killed all existing PTCs are destroyed at the same time.
@@ -1625,14 +1625,14 @@ The settings in this section control the behavior of the TTCN-3 Profiler. These
The following features can be enabled or disabled through the configuration file:
-* `DisableProfiler` – if set to `true`, the measurement of execution times is disabled and data related to execution times or average times will not be present in the statistics file. Default value: false
-* `DisableCoverage` – if set to `true`, the execution count of code lines and functions is not measured and data related to execution counts, average times or unused lines/functions will not be present in the statistics file. Default value: `false`
-* If both `DisableProfiler` and `DisableCoverage` are set to `true`, then the profiler acts as if it wasn’t activated in any of the modules (as if the compiler flag –z was not set). The database and statistics files are not generated.
-* `AggregateData` – if set to `true`, the data gathered in the previous run(s) is added to the current data, otherwise all previous data is discarded, default value: `false`
-* `DisableStatistics` – if set to `true`, the statistics file will not be generated at the end of execution, default value: `false`
-* `StartAutomatically` – if set to `true`, the profiler will start when the program execution starts, otherwise it will only start at the first @profiler.start command (it needs to be started individually for each component in parallel mode), default value: `true`
-* `NetLineTimes` – if set to `true`, the execution times of function calls will not be added to the caller lines’ total times, default value: `false`
-* `NetFunctionTimes` – if set to `true`, the execution times of function calls will not be added to the caller functions’ total times, default value: `false`
+* `DisableProfiler` - if set to `true`, the measurement of execution times is disabled and data related to execution times or average times will not be present in the statistics file. Default value: false
+* `DisableCoverage` - if set to `true`, the execution count of code lines and functions is not measured and data related to execution counts, average times or unused lines/functions will not be present in the statistics file. Default value: `false`
+* If both `DisableProfiler` and `DisableCoverage` are set to `true`, then the profiler acts as if it wasn’t activated in any of the modules (as if the compiler flag -z was not set). The database and statistics files are not generated.
+* `AggregateData` - if set to `true`, the data gathered in the previous run(s) is added to the current data, otherwise all previous data is discarded, default value: `false`
+* `DisableStatistics` - if set to `true`, the statistics file will not be generated at the end of execution, default value: `false`
+* `StartAutomatically` - if set to `true`, the profiler will start when the program execution starts, otherwise it will only start at the first @profiler.start command (it needs to be started individually for each component in parallel mode), default value: `true`
+* `NetLineTimes` - if set to `true`, the execution times of function calls will not be added to the caller lines’ total times, default value: `false`
+* `NetFunctionTimes` - if set to `true`, the execution times of function calls will not be added to the caller functions’ total times, default value: `false`
[[setting-output-files]]
=== Setting output files
@@ -1653,7 +1653,7 @@ The table below contains the list of available metacharacters in alphabetical or
[cols="m,",options="header",]
|===
|Meta-character |Substituted with . . .
-|%e |the name of the TTCN–3 executable. The `.exe` suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
+|%e |the name of the TTCN-3 executable. The `.exe` suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
|%h |the name of the computer returned by the `gethostname(2)` system call. This usually does not include the domain name.
|%l |the login name of the current user. If the login name cannot be determined (e.g. the current UNIX user ID has no associated login name) an empty string is returned.
|%p |the process ID `(pid)` of the UNIX process that implements the current test component. The `pid` is written in decimal notation.
diff --git a/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc b/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
index 408cf38c7b9e973ebfdc5d0db444315f6a678977..19c2945b074a8bc2ec323aaffe98ee3378c97cf3 100644
--- a/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
+++ b/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
@@ -14,7 +14,7 @@ Tpd files can be used without TITAN Designer for example for generating hierarch
TPD files are designed to be created by the Eclipse Designer but it can be created or modified by experts.
-The data is stored in XML format. The schema definition of the project descriptor is delivered with the Titan package and can be found in the `${TTCN3_DIR}/etc/xsd/TPD.xsd` file. If the type of an element is a subtype of string, for example a file name or a path, the xsd file doesn’t restrict it but uses only string or NormalizedString as type. Although the compliance of a TPD file for TPD.xsd is a necessary but not sufficient statement, it is very useful to verify the tpd file against TPD.xsd for example with this command: `xmllint –noout –schema XSD_FILE XML_FILE`
+The data is stored in XML format. The schema definition of the project descriptor is delivered with the Titan package and can be found in the `${TTCN3_DIR}/etc/xsd/TPD.xsd` file. If the type of an element is a subtype of string, for example a file name or a path, the xsd file doesn’t restrict it but uses only string or NormalizedString as type. Although the compliance of a TPD file for TPD.xsd is a necessary but not sufficient statement, it is very useful to verify the tpd file against TPD.xsd for example with this command: `xmllint -noout -schema XSD_FILE XML_FILE`
Each element is designed to be extendable, so for almost all elements there is a default value defined, if the element is missing this value is used.To simplify the reviews the elements are always saved in an ordered fashion thus limiting the effects of minor changes. The lists can contain from 0 to infinite elements. The O/M column in the tables describes if the element is optional or mandatory.
@@ -64,7 +64,7 @@ The following tags are supported:
|*Name of the attributes* |*Meaning* |*O/M*
|`name` |The name of the project referenced. This will create the relation between the actual and the referenced project. The value of this attribute must be equal to the `ProjectName` of the referenced project. |M
|`projectLocationURI` |The path of the project descriptor of the referenced project, relative to the actual descriptor. If the project is not already loaded in eclipse, it will be loaded from this path. |M
-|`tpdName` |The file name of the TPD file. This attribute is used with the `makefilegen’s` –I switch to provide search paths to find the referenced project if it is not found at `projectLocationURI`. |O
+|`tpdName` |The file name of the TPD file. This attribute is used with the `makefilegen’s` -I switch to provide search paths to find the referenced project if it is not found at `projectLocationURI`. |O
|===
Example:
@@ -136,7 +136,7 @@ Example:
The ActiveConfiguration element stores the name of the active build configuration whose parameters will be used by TITAN for building the project.
-NOTE: This can be overwritten from TITAN Designer (from Eclipse) or from command line generating Makefile(s) by ttcn3_makefilegen using the –b flag, see <<6-compiling_ttcn3_and_asn1_modules.adoc#using-the-makefile-generator-to-generate-makefile-s-from-titan-project-descriptor-file-s, here>>.
+NOTE: This can be overwritten from TITAN Designer (from Eclipse) or from command line generating Makefile(s) by ttcn3_makefilegen using the -b flag, see <<6-compiling_ttcn3_and_asn1_modules.adoc#using-the-makefile-generator-to-generate-makefile-s-from-titan-project-descriptor-file-s, here>>.
See also chapter <<configurations, Configurations>>.
@@ -201,7 +201,7 @@ Useful information can be found in TITAN Designer documentation <<13-references.
|`functiontestRuntime (use function test runtime (TITAN_RUNTIME_2)` |-R |-R |false |O
|`singleMode` |-s |- |false |O
|`codeSplitting (select code splitting mode for the generated {cpp} code)` |-U |-U |none |O
-|`defaultTarget ("executable" or "library", if –L applied, see 6.1.2)` |-L |- |executable |O
+|`defaultTarget ("executable" or "library", if -L applied, see 6.1.2)` |-L |- |executable |O
|`targetExecutable` |-e |- |N/A |O
|`TTCN3preprocessor (the name of the preprocessor meaningful only in Eclipse)` |- |- |cpp |O
|`TTCN3preprocessorIncludes` |- |- |empty |O
@@ -280,7 +280,7 @@ Contents of the `ProjectSpecificRulesGenerator` element:
Exactly one `GeneratorCommand` element that specifies the external command to be run
-An optional Targets element that contains any number of Target elements, each element having two attributes: name – name of the target, placement – the place of where the target shall be inserted. Possible places are defined in the TPD.xsd file.
+An optional Targets element that contains any number of Target elements, each element having two attributes: name - name of the target, placement - the place of where the target shall be inserted. Possible places are defined in the TPD.xsd file.
The content of the `profiledFileList` element is the path to a text file, using the same path attributes as `FileResource` elements. The text file contains the list of files (TTCN-3 modules), that will be profiled, separated by new lines. This file is stored in the variable `PROFILED_FILE_LIST` in the generated makefile.
diff --git a/usrguide/referenceguide/9-xsd_to_ttcn-3_converter.adoc b/usrguide/referenceguide/9-xsd_to_ttcn-3_converter.adoc
index 365888f39a5e7d424aa93aad7fa817dc817c3d09..a79d3e5a27fe22f8b6cabf4e3065578783f224b5 100644
--- a/usrguide/referenceguide/9-xsd_to_ttcn-3_converter.adoc
+++ b/usrguide/referenceguide/9-xsd_to_ttcn-3_converter.adoc
@@ -295,7 +295,7 @@ Information in the `appinfo` tags are not translated.
== Extensions
-The XSD to TTCN-3 Converted has the following non-standard additions to the Using XML Schema with TTCN–3 <<13-references.adoc#_4, [4]>> .
+The XSD to TTCN-3 Converted has the following non-standard additions to the Using XML Schema with TTCN-3 <<13-references.adoc#_4, [4]>> .
TITAN allows the usage of constants and module parameters in the value of a `defaultForEmpty` encoding instruction. The `xsd2ttcn` tool generates the `defaultForEmpty` encoding instructions with a constant definition as a value to provide reusability of the `defaultForEmpty` values. Only the conversion of `default` and `fixed` attributes of elements is changed.
diff --git a/usrguide/referenceguide/ReferenceGuide.adoc b/usrguide/referenceguide/ReferenceGuide.adoc
index 27b987299fd0b81d525288fe0a9c82c61f65c4cb..8236596372fd9cc1569632e71a711b73dcce5b0b 100644
--- a/usrguide/referenceguide/ReferenceGuide.adoc
+++ b/usrguide/referenceguide/ReferenceGuide.adoc
@@ -35,9 +35,9 @@ ifdef::env-github,backend-html5[]
* link:1-about_the_document.adoc[About the document]
* link:2-ttcn-3_limitations_in_this_version.adoc[TTCN-3 Limitations in this Version]
* link:3-clarifications_to_the_ttcn-3_standard.adoc[Clarifications to the TTCN-3 Standard]
-* link:4-ttcn3_language_extensions.adoc[TTCN–3 Language Extensions]
+* link:4-ttcn3_language_extensions.adoc[TTCN-3 Language Extensions]
* link:5-supported_asn1_constructs_and_limitations.adoc[Supported ASN.1 Constructs and Limitations]
-* link:6-compiling_ttcn3_and_asn1_modules.adoc[Compiling TTCN–3 and ASN.1 Modules]
+* link:6-compiling_ttcn3_and_asn1_modules.adoc[Compiling TTCN-3 and ASN.1 Modules]
* link:7-the_run-time_configuration_file.adoc[The Run-time Configuration File]
* link:8-the_titan_project_descriptor_file.adoc[The TITAN Project Descriptor File]
* link:9-xsd_to_ttcn-3_converter.adoc[XSD to TTCN-3 Converter]