titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2022-08-22T08:49:20Zhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/616Dash not accepted as actual parameter value for out parameter2022-08-22T08:49:20ZLevente ErősDash not accepted as actual parameter value for out parameter## Summary
The actual value of an out parameter can be specified as '-' according to 5.4.2 paragraph 3 of the TTCN-3 standard. Yet, TITAN does not accept it.
## Steps and/or TTCN-3 code to reproduce
Create a module including the follo...## Summary
The actual value of an out parameter can be specified as '-' according to 5.4.2 paragraph 3 of the TTCN-3 standard. Yet, TITAN does not accept it.
## Steps and/or TTCN-3 code to reproduce
Create a module including the following:
```
function fn_dash_actual_parameter_value_in_out_inout (in integer ip, out integer op, inout integer iop){
op := iop;
iop := ip;
}
testcase tc_dash_actual_parameter_value_in_out_inout() runs on ct_empty{
var integer vo := 2;
var integer vio := 3;
fn_dash_actual_parameter_value_in_out_inout(1,-,vio);//should work
}
```
Run the testcase.
## What is the current bug behavior?
Error message "Not used symbol (`-') cannot be used for parameter that does not have default value" is returned during compilation and on the GUI.
## What is the expected correct behavior?
The code shall compile.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.2
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/630dash (unchanged) assignment does not work with set/record of types and assign...2022-08-23T07:21:38ZLevente Erősdash (unchanged) assignment does not work with set/record of types and assignment notation## Summary
When assigning a value to a set of or record of data instance using assignment notation, the unchanged (-) special value cannot be used as TITAN gives an error message in return.
## Steps and/or TTCN-3 code to reproduce
Cre...## Summary
When assigning a value to a set of or record of data instance using assignment notation, the unchanged (-) special value cannot be used as TITAN gives an error message in return.
## Steps and/or TTCN-3 code to reproduce
Create a module with the following content:
```
type record of bitstring MyRecordOfType;
testcase record_of_set_of_assignments() runs on ct_empty{
var MyRecordOfType v_myVariable := {
[0] := -,
[1] := '101'B,
[2] := -
};
if(not isbound(v_myVariable[0]) and v_myVariable[1]=='101'B and not isbound(v_myVariable[2])){setverdict(pass);}
}
```
Try to compile it.
## What is the current bug behavior?
dash assignments yield an error.
## What is the expected correct behavior?
Test case should pass.
## Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code, as it's very hard to read otherwise.)
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/576Debian packet creation fails2022-05-04T05:36:28ZLenard NagyDebian packet creation fails## Summary
Debian packet creation fails with following log:
```
--- /dev/null
+++ eclipse-titan-8.1.0/common/git_version.c
@@ -0,0 +1,4 @@
+// this file was generated by make
+#include "version_internal.h"
+
+char const *const GIT_COMM...## Summary
Debian packet creation fails with following log:
```
--- /dev/null
+++ eclipse-titan-8.1.0/common/git_version.c
@@ -0,0 +1,4 @@
+// this file was generated by make
+#include "version_internal.h"
+
+char const *const GIT_COMMIT_ID = "";
\ No newline at end of file
```
## Steps and/or TTCN-3 code to reproduce
-
## What is the current bug behavior?
-
## What is the expected correct behavior?
Packet creation succeeds
## Relevant logs and/or screenshots
```
--- /dev/null
+++ eclipse-titan-8.1.0/common/git_version.c
@@ -0,0 +1,4 @@
+// this file was generated by make
+#include "version_internal.h"
+
+char const *const GIT_COMMIT_ID = "";
\ No newline at end of file
```
## Possible fixes
One new line character must be the last character of all C/C++ source files, in this case common/git_version.c
## Titan version
8.0.0
## Platform details (OS type and version)
Debian (latest)
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/544Decoding broken in Titan 7.2.22021-11-10T08:29:51ZEclipse WebmasterDecoding broken in Titan 7.2.2## Submitted by Anton Vikstrom
**[Link to original bug (#572603)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=572603)**
## Description
Created attachment 286037
Minimal example showing the problem
When we upgraded to Ti...## Submitted by Anton Vikstrom
**[Link to original bug (#572603)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=572603)**
## Description
Created attachment 286037
Minimal example showing the problem
When we upgraded to Titan 7.2.2 from Titan 7.1, most of our testcases started failing. It turns out decoding is broken.
I have attached a minimal testcase using PFCP_v16.4.0_4_CNL113875 R1H to decode a PDU. I there match the result of the decoding with the result of the decoding when using Titan 7.1. Of course, with Titan 7.1, this testcase passed. With Titan 7.2.2, this testcase FAILS.
The decode result in Titan 7.2.2 has many unbound fields, even mandatory ones like "spare := `<unbound>`" in SDF_Filter. You can also find instances of FAR_ID with elementIdentifier 109, even though it should always be 108.
This issue is urgent.
**Attachment 286037**, "Minimal example showing the problem":
[tc_decode.ttcn](/uploads/48147aa0e6fc07fe2b545c72c8d64f89/tc_decode.ttcn)
Version: 7.2.1https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/672default as module parameter type is allowed in Titan2023-11-15T09:58:29ZLevente Erősdefault as module parameter type is allowed in Titan## Summary
According to Section 8.2.1, Restriction b), module parameters shall not be of default type. However, TITAN allows for this.
## Steps and/or TTCN-3 code to reproduce
```
module modules{
type component ct_empty{}
modulepar ...## Summary
According to Section 8.2.1, Restriction b), module parameters shall not be of default type. However, TITAN allows for this.
## Steps and/or TTCN-3 code to reproduce
```
module modules{
type component ct_empty{}
modulepar default d; //wrong
testcase mp_def_val() runs on ct_empty{
log(d);
}
control{
execute(mp_def_val());
}
}
```
## What is the current bug behavior?
unbound default is logged
## What is the expected correct behavior?
compliation error
## Relevant logs and/or screenshots
```
2022/Dec/06 08:57:24.298261 USER - <unbound>
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/635default union field does not work2024-02-02T17:08:50ZLevente Erősdefault union field does not work## Summary
Union field shall be able to be annotated as @default. In this case, a union data element can be assigned a value without explicitly identifying the field name. Titan does not support this right now.
## Steps and/or TTCN-3 c...## Summary
Union field shall be able to be annotated as @default. In this case, a union data element can be assigned a value without explicitly identifying the field name. Titan does not support this right now.
## Steps and/or TTCN-3 code to reproduce
Create a module with the following contents:
```
type union myut{
@default
integer field1,
charstring field2
}
testcase union_def() runs on ct_empty{
var myut v;
v.field1 := 1;
v.field2 := "a";
v := {field1:=2};
v := {field2:="b"};
//v := 3; //error
v.field1 := 3;
v := 4;
if(v.field1==4){setverdict(pass);}
}
```
Compile.
## What is the current bug behavior?
Titan does not recognize the @default annotation.
## What is the expected correct behavior?
The above code should run and pass. When the (uncommented) v:=3 row is processed, it should yield an error, as value assignment is only possible without identifying the union field if the default field is the chosen field at that point in time. For the same reason, the v := 4 row should not cause an error, as right before it field1 was chosen.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/583Document effects of [INCLUDE] and [ORDERED_INCLUDE] sections in config files2022-05-04T05:39:27ZLenard NagyDocument effects of [INCLUDE] and [ORDERED_INCLUDE] sections in config files## Summary
[ORDERED_INCLUDE] may include more files in order, and it may have sideeffects (e.g. [EXECUTE] section is present it is executed more times, or "&=" will add multiple module paramters)
The behavior is as expected, but this h...## Summary
[ORDERED_INCLUDE] may include more files in order, and it may have sideeffects (e.g. [EXECUTE] section is present it is executed more times, or "&=" will add multiple module paramters)
The behavior is as expected, but this has to be documented to avoid confusion.
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/409dual port bug2021-05-05T12:42:29ZEclipse Webmasterdual port bug## Submitted by Izabella Ingrid Farkas
**[Link to original bug (#538149)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=538149)**
## Description
The in section not decoding PDUType1.
type port PT2GEN message {
inout PD...## Submitted by Izabella Ingrid Farkas
**[Link to original bug (#538149)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=538149)**
## Description
The in section not decoding PDUType1.
type port PT2GEN message {
inout PDUType1, PDUType2;
inout octetstring;
} with { extension "user PT1
out( PDUType1 -> octetstring: function(enc_PDUType1_gen); /* call function */
PDUType2 -> octetstring: encode(RAW); /* call built-in codec */
octetstring -> PDUType1: function(dec_slider_gen) /* outgoing map with a prototype(sliding) decode(...) !! */
)
in( octetstring -> PDUType2: function(dec_slider_gen2) /* call function; prototype(sliding) */
, PDUType1: decode(RAW) /* built-in decoder */
)"
}
Version: 6.4.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/605Enumerated compatibility doesn't work as expected.2022-05-13T14:53:04ZLevente ErősEnumerated compatibility doesn't work as expected.## Summary
Enumerated values can be compatible according to the current TTCN-3 standard, but TITAN does now know that.
## Steps and/or TTCN-3 code to reproduce
```
type enumerated EWeekDays {
Mon, Tue, Wed, Thu, Fri, Sat, Sun
};
typ...## Summary
Enumerated values can be compatible according to the current TTCN-3 standard, but TITAN does now know that.
## Steps and/or TTCN-3 code to reproduce
```
type enumerated EWeekDays {
Mon, Tue, Wed, Thu, Fri, Sat, Sun
};
type enumerated EWorkDays {
Mon, Tue, Wed, Thu, Fri
};
control{
var EWeekDays v_myWeekDayMon := Mon
var EWorkDays v_myWorkDayMon := Mon
v_myWorkDayMon := v_myWeekDayMon
}
```
## What is the current bug behavior?
Compilation fails, as the RHS of the assignment has a different type to that of the LHS of the assignment.
## What is the expected correct behavior?
The code should be compiled as the RHS of the assignment is compatible with the type of the LHS of the assignment, because the value on the RHS is defined in the type of the LHS, and is defined with the same associated integer. (Section 6.3.2.1)
## Relevant logs and/or screenshots
```
**************************************************************
2022-05-13_16:21:52: starting to build address
**************************************************************
sh -c make dep
/home/lee/git/titan.core/Install/bin/compiler \
../src/maptest.ttcn ../src/subtypes.ttcn - ../src/maptest.ttcn ../src/subtypes.ttcn
Notify: Parsing TTCN-3 module `../src/maptest.ttcn'...
Notify: Parsing TTCN-3 module `../src/subtypes.ttcn'...
Notify: Checking modules...
../src/maptest.ttcn: In TTCN-3 module `maptest':
../src/maptest.ttcn:11.1-15.1: In control part:
../src/maptest.ttcn:14.3-34: In variable assignment:
../src/maptest.ttcn:14.21-34: error: Type mismatch: a value of type `@maptest.EWorkDays' was expected instead of `@maptest.EWeekDays'
Notify: Error found in the input modules. Code will not be generated.
make: *** [Makefile:154: compile] Error 1
Operation failed with return value: 2
```
## Possible fixes
If a value 'a' from enumerated type 'A' is assigned to a data element of enumerated type 'B' then the assignment shall be successful if 'a' is defined in enumerated type 'B' as well, and is defined with the same associated integer as in 'A'. (See 6.2.4, EXAMPLE 3 mainly)
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/646Enumerated compatibility is stricter in TITAN than in TTCN-3 standard2024-01-15T16:49:20ZLevente ErősEnumerated compatibility is stricter in TITAN than in TTCN-3 standard## Summary
Enumerated compatibility needs identical enumerated types to work in TITAN, while the standard (6.3.2.1) is more relaxed on this matter.
## Steps and/or TTCN-3 code to reproduce
```
type enumerated EWeekDays {
Mon, Tue, W...## Summary
Enumerated compatibility needs identical enumerated types to work in TITAN, while the standard (6.3.2.1) is more relaxed on this matter.
## Steps and/or TTCN-3 code to reproduce
```
type enumerated EWeekDays {
Mon, Tue, Wed, Thu, Fri, Sat, Sun
};
type enumerated EWorkDays {
Mon, Tue, Wed, Thu, Fri
};
type enumerated EComplexValues {
e_num (1),
e_expr (2+2),
e_bin_conv (bit2int('0111'B)),
e_oct_conv (oct2int('34'O)),
e_hex_conv (hex2int('AC'H))
}
type enumerated ESimpleValues {
e_num (1),
e_expr (4),
e_bin_conv (7),
e_oct_conv (52),
e_hex_conv (172)
}
testcase enum_comp() runs on ct_empty{
var EWeekDays v_myWeekDayMon := Mon
var EWorkDays v_myWorkDayMon := Mon
var EComplexValues v_myComplexValuedEnum := e_bin_conv;
var ESimpleValues v_mySimpleValuedEnum := e_bin_conv;
v_myWorkDayMon := v_myWeekDayMon
v_mySimpleValuedEnum := v_myComplexValuedEnum;
}
```
## What is the current bug behavior?
Errors
## What is the expected correct behavior?
The two last assignments shall work as the assigned value exists in the domain of the assignee and its identifier is the same too.
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:509.21-34: error: Type mismatch: a value of type `@datatypes.EWorkDays' was expected instead of `@datatypes.EWeekDays'
../src/datatypes.ttcn:510.27-47: error: Type mismatch: a value of type `@datatypes.ESimpleValues' was expected instead of `@datatypes.EComplexValues'
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/666Enumerated compatibility is too restrictive2024-01-15T16:49:30ZLevente ErősEnumerated compatibility is too restrictive## Summary
According to section 7.1.3 of the standard, same values of different enumerated types are equal if name and id are same and the two types can be converged into a consistent type (no name-id contradictions appear). Titan does ...## Summary
According to section 7.1.3 of the standard, same values of different enumerated types are equal if name and id are same and the two types can be converged into a consistent type (no name-id contradictions appear). Titan does not accept the equality check of two non-identical enumerated types though.
Note: The standard contradicts itself here: 6.2.4. contradicts the above section.
## Steps and/or TTCN-3 code to reproduce
```
type component ct_empty{}
type enumerated enum1 {egyes(1), kettes(2)};
type enumerated enum2 {kettes(2), harmas (3)};
testcase alloperators() runs on ct_empty{
var enum1 e1 := kettes;
var enum2 e2 := kettes;
if(e1==e2){setverdict(pass);}else{setverdict(fail);}
}
control{
execute(alloperators());
}
```
## What is the current bug behavior?
Error.
## What is the expected correct behavior?
Pass.
## Relevant logs and/or screenshots
```../src/operators.ttcn:49.10-11: error: Type mismatch: a value of type `@operators.enum1' was expected instead of `@operators.enum2'```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/633Enumerated domain elements with integer value range/list cannot be defined an...2022-08-24T12:28:05ZLevente ErősEnumerated domain elements with integer value range/list cannot be defined and used## Summary
According to the TTCN-3 standard (section 6.2.4) when assigning integer identifiers to enumerated type domain elements, assigning a single integer as identifier is not the only legal case. It is also legal to define a set of ...## Summary
According to the TTCN-3 standard (section 6.2.4) when assigning integer identifiers to enumerated type domain elements, assigning a single integer as identifier is not the only legal case. It is also legal to define a set of integers for the given enumerated type domain element. Titan however, only supports the former case.
## Steps and/or TTCN-3 code to reproduce
Use this code in a new module:
```
type enumerated MyThirdEnumType {
Blue(0),
Yellow(1),
Green(3),
Other(2, 4..255)
}
testcase enum_list() runs on ct_empty{
var MyThirdEnumType v_color := Other(5);
if (v_color == Other(4)) {}
if (v_color > Other(4)) {}
if (match(v_color, Other(?))) {}
if (match(v_color, Other(6..10))) {}
if (match(v_color, Other((6..10), 15, 20..25))) {}
setverdict(pass);
}
```
## What is the current bug behavior?
This will not compile
## What is the expected correct behavior?
How it should work on the other hand, is:
- any enum value defnied with a set of integers as identifier shall be referred to with its name and the chosen identifier in parentheses. Other(4) and Other(5) shall be handled as different values of the same type.
- such enum values shall also be usable as templates (like in the bottom 3 examples).
Thus, the above code should not cause errors, the testcase should pass.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/578Enumerated type subtype check2022-05-04T05:41:09ZAdam KnappEnumerated type subtype check## Summary
According to the standard (6.2.13.2, https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.13.01_60/es_20187301v041301p.pdf#page=80): "In case of enumerated types, the template list subtyping shall contain only value...## Summary
According to the standard (6.2.13.2, https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.13.01_60/es_20187301v041301p.pdf#page=80): "In case of enumerated types, the template list subtyping shall contain only values of the parent type."
## Steps and/or TTCN-3 code to reproduce
```
type enumerated MyEnum { e_first, e_second, e_third, e_fourth, e_fifth };
type MyEnum EnumSub4 ( EnumSub1, e_fourth);
// causes an error as type references are not allowed in the template list
// of enumerated types
```
## What is the current bug behavior?
It is allowed/not checked by the compiler.
## What is the expected correct behavior?
The compiler should provide an error message about this.
## Titan version
6.6.1
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/592Error during parallel make2022-08-29T06:35:47ZGergely PilisiError during parallel make## Summary
The make process fails when parallel compiling is enabled. The error message is this:
mv: cannot stat 'TitanLoggerApi.ttcn_': No such file or directory
make[4]: *** [Makefile:280: TitanLoggerApi.ttcn] Error 1
Please visit t...## Summary
The make process fails when parallel compiling is enabled. The error message is this:
mv: cannot stat 'TitanLoggerApi.ttcn_': No such file or directory
make[4]: *** [Makefile:280: TitanLoggerApi.ttcn] Error 1
Please visit this URL for more information: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987646
## Steps and/or TTCN-3 code to reproduce
Build Titan without --no-parallel option and the process will fail sometimes.
## What is the current bug behavior?
It's not consistent, sometimes the build succeeds, sometimes fails with the error above.
## What is the expected correct behavior?
Stable builds without --no-parallel option.
## Relevant logs and/or screenshots
```
mv TitanLoggerApi.ttcn_ TitanLoggerApi.ttcn
mv TitanLoggerApi.ttcn_ TitanLoggerApi.ttcn
mv: cannot stat 'TitanLoggerApi.ttcn_': No such file or directory
make[4]: *** [Makefile:280: TitanLoggerApi.ttcn] Error 1
```
## Possible fixes
N/A
## Titan version
All versions involved.
## Platform details (OS type and version)
Various x86_64 Debian versions. The bug is platform independent.
/cc @aknappqwtMiklos MagyariMiklos Magyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/721Error when generating PER descriptor containing reference to a constant in an...2024-03-27T16:52:57ZBotond BaranyiError when generating PER descriptor containing reference to a constant in another module## Summary
ASN.1 type constraints can contain references to constants, which are generated into the C++ code if these constraints are relevant to PER. If the referenced constant is defined in another ASN.1 module, then the compiler cras...## Summary
ASN.1 type constraints can contain references to constants, which are generated into the C++ code if these constraints are relevant to PER. If the referenced constant is defined in another ASN.1 module, then the compiler crashes with a fatal error.
## Steps and/or TTCN-3 code to reproduce
Imported module:
`objid-val OBJECT IDENTIFIER ::= { itu-t(0) recommendation(0) a(1) b(3) }`
Importing module:
`CharStr ::= CHARACTER STRING ( WITH COMPONENTS { identification ( syntaxes: { abstract objid-val, transfer objid-val } ) } )`
## What is the current bug behavior?
Compiler crashes with a fatal error
## What is the expected correct behavior?
Successful code generation
## Relevant logs and/or screenshots
-
## Possible fixes
Implement Ref_defd::generate_code_const_ref()
## Titan version
10.0.0
## Platform details (OS type and version)
Ubuntu 22.04
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/669evaluation does not stop where it should2023-11-17T07:10:28ZLevente Erősevaluation does not stop where it should## Summary
According section 7.1.4 of the TTCN-3 standard, "Short circuit evaluation for boolean expressions is used, i.e. the evaluation of operands of logical operators is stopped once the overall result is known: in the case of the a...## Summary
According section 7.1.4 of the TTCN-3 standard, "Short circuit evaluation for boolean expressions is used, i.e. the evaluation of operands of logical operators is stopped once the overall result is known: in the case of the and operator, if the left argument evaluates to false, then the right argument is not evaluated and the whole expression evaluates to false. In the case of the or operator, if the left argument evaluates to true, then the right argument is not evaluated and the whole expression evaluates to true."
## Steps and/or TTCN-3 code to reproduce
```
testcase logicalops() runs on ct_empty{
var integer v:=0;
var integer u:=0;
if(true or (u/v==1)){setverdict(pass);}else{setverdict(fail);}
if(not(false or (u/v==1))){setverdict(pass);}else{setverdict(fail);}
}
```
## What is the current bug behavior?
Pass
## What is the expected correct behavior?
Error, as there is a division by 0 in the 2nd operand -- but this operand shall not be reached during evaluation
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/696Extension additions of a SEQUENCE/SET are not set to optional2023-09-06T12:59:16ZAdam KnappExtension additions of a SEQUENCE/SET are not set to optional## Summary
According to the ASN.1 standard, "All fields in extension additions of a SEQUENCE type or a SET type shall be transformed to optional fields". This behavior is missing currently.
Originates from this forum post: https://www....## Summary
According to the ASN.1 standard, "All fields in extension additions of a SEQUENCE type or a SET type shall be transformed to optional fields". This behavior is missing currently.
Originates from this forum post: https://www.eclipse.org/forums/index.php/t/1112865/
## Titan version
All
## Platform details (OS type and version)
All
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/636FATAL ERROR: ttcn3_compiler: In line 11645 of AST_ttcn3.cc: ActualPar::set_my...2023-05-16T10:53:42ZPau Espin PedrolFATAL ERROR: ttcn3_compiler: In line 11645 of AST_ttcn3.cc: ActualPar::set_my_scope()## Summary
ttcn3_compiler aborts while compiling:
```
FATAL ERROR: /usr/ttcn3/bin/ttcn3_compiler: In line 11645 of AST_ttcn3.cc: ActualPar::set_my_scope()
make[1]: *** [Makefile:206: compile] Aborted (core dumped)
make[1]: Leaving direc...## Summary
ttcn3_compiler aborts while compiling:
```
FATAL ERROR: /usr/ttcn3/bin/ttcn3_compiler: In line 11645 of AST_ttcn3.cc: ActualPar::set_my_scope()
make[1]: *** [Makefile:206: compile] Aborted (core dumped)
make[1]: Leaving directory '/home/pespin/dev/sysmocom/ttcn3/osmo-ttcn3-hacks/bts'
```
## Steps and/or TTCN-3 code to reproduce
I have one such module I was writing:
```
module OSMUX_Types {
import from General_Types all;
import from Misc_Helpers all;
import from AMR_Types all;
external function enc_OSMUX_PDU ( in OSMUX_PDU msg ) return octetstring
with { extension "prototype(convert) encode(RAW)" };
external function dec_OSMUX_PDU ( in octetstring msg ) return OSMUX_PDU
with { extension "prototype(convert) decode(RAW)" };
type INT1 OsmuxCID (0 .. 255);
type enumerated OsmuxFT {
OSMUX_FT_LAPD,
OSMUX_FT_AMR,
OSMUX_FT_DUMMY
};
type record Osmux_AMR_header {
BIT1 marker,
INT2b ft,
INT3b ctr,
BIT1 amr_f,
BIT1 amr_q,
INT1 seq,
OsmuxCID cid,
INT4b amr_ft,
INT4b amr_cmr
} with {
variant "FIELDORDER(msb)"
}
type record PDU_Osmux_AMR {
Osmux_AMR_header header,
octetstring data
} with {
variant "FIELDORDER(msb)"
};
type record PDU_Osmux_DUMMY {
Osmux_AMR_header header,
octetstring data
} with {
variant "FIELDORDER(msb)"
};
type record Osmux_session_par {
integer id optional,
charstring local_address optional,
integer local_port optional,
charstring dest_address optional,
integer dest_port optional
}
type record ASP_Osmux_Open_session {
Osmux_session_par session_id
}
type record ASP_Osmux_Open_session_result {
Osmux_session_par session_id
}
type record ASP_Osmux_Close_session {
Osmux_session_par session_id
}
type union OSMUX_PDU {
PDU_Osmux_AMR osmux_amr,
PDU_Osmux_DUMMY osmux_dummy
} with {
variant "TAG (
osmux_amr, header.ft = 1;
osmux_dummy, header.ft = 2;
)"
};
template (present) PDU_Osmux_AMR tr_OsmuxAMR(template (present) BIT1 marker := ?,
template (present) INT3b ctr := ?,
template (present) BIT1 amr_f := ?,
template (present) BIT1 amr_q := ?,
template (present) INT1 seq := ?,
template (present) OsmuxCID cid := ?,
template (present) INT4b amr_ft := ?,
template (present) INT4b amr_cmr := ?,
octetstring payload := ?) := {
header := {
marker := marker,
ft := 1,
ctr := ctr,
amr_f := amr_f,
amr_q := amr_q,
seq := seq,
cid := cid,
amr_ft := amr_ft,
amr_cmr := amr_cmr
},
data := payload
}
} with { encode "RAW"}
```
Then, I tried to set a template like this, which triggers the compiler crash:
```
var template (present) PDU_Osmux_AMR osmux_pdu_exp := tr_OsmuxAMR(cid := g_pars.loc_osmux_cid,
amr_ft := amr_ft,
amr_cmr := amr_ft);
```
## What is the current bug behavior?
The compiler aborts with the above provided message.
## What is the expected correct behavior?
Don't crash, do what it's requested ;)
## Titan version
```
$ ttcn3_compiler -v
warning: Charstring pattern: Cannot open file '/usr/ttcn3/etc/CaseFolding.txt' for reading. Case-insensitive universal charstring patterns are disabled.
TTCN-3 and ASN.1 Compiler for the TTCN-3 Test Executor
Version: 8.1.0
Build date: Apr 12 2022 20:55:42
Compiled with: GCC 11.2.0
Using OpenSSL 1.1.1q 5 Jul 2022
Commit id: 6be5a7f23
```
Copyright (c) 2000-2021 Ericsson Telecom AB
## Platform details (OS type and version)
(OS type/distribution and version, e.g. Ubuntu 18.04, Windows 10+Cygwin)
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/481Faulty subtype checking2022-09-21T13:23:43ZEclipse WebmasterFaulty subtype checking## Submitted by Gabor Szalai
**[Link to original bug (#562085)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562085)**
## Description
The following subtyping is a valid according to the standard but not accepted by the TI...## Submitted by Gabor Szalai
**[Link to original bug (#562085)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562085)**
## Description
The following subtyping is a valid according to the standard but not accepted by the TITAN:
type set r1 {
charstring f1,
charstring f3 optional
}
type r1 r1s ({f3:=omit})
proba.ttcn:10.14-24: error: Field `f1' is missing from set value
6.2.13.2:
When constraining record and set types, templates of the expanded list defined using the value list notation shall be valid (i.e. complete) templates, while templates of the expanded list defined using the field assignment notation may be partial (i.e. incomplete). In the latter case, the fields that are not explicitly present shall be considered as containing AnyValue for mandatory fields and AnyValueOrNone for optional fields.
Version: 6.6.1Adam KnappAdam Knapp2022-05-04https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/506Float string representation precision problems2021-11-10T08:29:07ZEclipse WebmasterFloat string representation precision problems## Submitted by G??bor Szalai
**[Link to original bug (#566118)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=566118)**
## Description
The string representation of the TTCN-3 floats are not precise enough. Less significan...## Submitted by G??bor Szalai
**[Link to original bug (#566118)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=566118)**
## Description
The string representation of the TTCN-3 floats are not precise enough. Less significant digits are used than required.
Examples:
Code generation problems:
TTCN code
var float fl:= 1.0000000000000002 // smallest value greater than 1 representable by 64bit double
Generated C++ code:
fl = 1;
Other problematic example: 3.2511111111111113e123
The same precision problem exists in:
string2ttcn
JSON encoder
float2str
The number of the needed significant digits are depends on the used floating point type. In the case of the double at least 17 digits are needed.
Version: 7.1.0