titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2024-01-11T15:16:52Zhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/677inter-language imports allowed from younger language2024-01-11T15:16:52ZLevente Erősinter-language imports allowed from younger language## Summary
According to Section 8.2.3, point c) of the TTCN-3 standard, "the TTCN-3 language specification in an import statement has to be lower or equal to the TTCN-3
language specification of the importing module".
## Steps and/or T...## Summary
According to Section 8.2.3, point c) of the TTCN-3 standard, "the TTCN-3 language specification in an import statement has to be lower or equal to the TTCN-3
language specification of the importing module".
## Steps and/or TTCN-3 code to reproduce
```
module modules language "TTCN-3:2003"{
type component ct_empty{}
import from F language "TTCN-3:2010" all; //ERROR```
testcase oldimport() runs on ct_empty{
var oldint voi := 1;
setverdict(pass);
}
}
```
also
```
module F language "TTCN-3:2010"{
type integer oldint
}
```
## What is the current bug behavior?
Code compiles and passes.
## What is the expected correct behavior?
Compilation or runtime error due to the import language clause being greater than the language clause of module ```modules```.
## 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/647Record compatibility is too restrictive in Titan2023-11-15T09:58:34ZLevente ErősRecord compatibility is too restrictive in Titan## Summary
Record compatibility requires type name equivalence while standard does not.
## Steps and/or TTCN-3 code to reproduce
```
type record AType {
integer a(0..10) optional,
integer b(0..10) optional,
boolean c
}
type reco...## Summary
Record compatibility requires type name equivalence while standard does not.
## Steps and/or TTCN-3 code to reproduce
```
type record AType {
integer a(0..10) optional,
integer b(0..10) optional,
boolean c
}
type record BType {
integer a optional,
integer b(0..10) optional,
boolean c
}
type record CType {
// type with different field names
integer d optional,
integer e optional,
boolean f
}
type record DType {
// type with field c optional
integer a optional,
integer b optional,
boolean c optional
}
type record EType {
// type with an extra field d
integer a optional,
integer b optional,
boolean c,
float d optional
}
testcase record_comp() runs on ct_empty{
var AType v_myVarA := { -, 1, true};
var BType v_myVarB := { omit, 2, true};
var CType v_myVarC := { 3, omit, true};
v_myVarA := v_myVarB; //error
v_myVarC := v_myVarB; //error
v_myVarC := { d:= 20 };
v_myVarA := v_myVarC; //error
}
```
## What is the current bug behavior?
Errors in the indicated lines.
## What is the expected correct behavior?
These assignments shall succeed: Titan should only take into consideration the (written form of the) value that is assigned, not its type (and not the field names).
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:553.3-22: In variable assignment:
../src/datatypes.ttcn:553.15-22: error: Type mismatch: a value of type `@datatypes.AType' was expected instead of `@datatypes.BType'
../src/datatypes.ttcn:554.3-22: In variable assignment:
../src/datatypes.ttcn:554.15-22: error: Type mismatch: a value of type `@datatypes.CType' was expected instead of `@datatypes.BType'
../src/datatypes.ttcn:558.3-22: In variable assignment:
../src/datatypes.ttcn:558.15-22: error: Type mismatch: a value of type `@datatypes.AType' was expected instead of `@datatypes.CType'
```
## 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/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/678importing imports does not work2023-11-15T09:57:56ZLevente Erősimporting imports does not work## Summary
The mechanism defined in Section 8.2.3.7 of the TTCN-3 standard for importing import statements does not work.
## Steps and/or TTCN-3 code to reproduce
In one module
```
import from chain1 {import all};
testcase importimpo...## Summary
The mechanism defined in Section 8.2.3.7 of the TTCN-3 standard for importing import statements does not work.
## Steps and/or TTCN-3 code to reproduce
In one module
```
import from chain1 {import all};
testcase importimport() runs on ct_empty{
// log(chain2const); //ERROR
// log(chain32const); //ERROR
log(chain33const); //should work
}
```
Furthermore the following modules are needed:
```
module chain1 {
private import from chain2 {import all}; //importing module does not see chain2const
import from chain22 {import all}; //importing module does not see chain32const
public import from chain23 {import all}; //importing module does see chain33const
}
```
```
module chain2 {
import from chain3 all;
}
```
```
module chain22 {
import from chain32 all;
}
```
```
module chain23 {
import from chain33 all;
}
```
```
module chain3 {
const integer chain2const := 1;
}
```
```
module chain32 {
const integer chain32const := 1;
}
```
```
module chain33 {
const integer chain33const := 1;
}
```
## What is the current bug behavior?
chain33const is not seen in the main module.
## What is the expected correct behavior?
chain33const shoulw be seen in the main module while the commented-out two constants should not be seen.
## 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 @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/681Clashing enumerated identifiers unrecognized by Titan2023-11-15T09:57:46ZLevente ErősClashing enumerated identifiers unrecognized by Titan## Summary
According to sections 6.2.4 and 8.2.3.1 of the TTCN-3 standard, the identifier of a data element with an enumerated type cannot be identical to any element of the domain of the given enumerated type. For example, in the below...## Summary
According to sections 6.2.4 and 8.2.3.1 of the TTCN-3 standard, the identifier of a data element with an enumerated type cannot be identical to any element of the domain of the given enumerated type. For example, in the below example enumY cannot be the identifier of a MyEnumType variable for the following reason: When assigning enumY as the value of another MyEnumType variable enumW, it is ambiguous whether the value of variable enumY (which is enumX) or the emunerated domain value enumY is intended to be assigned to enumW.
## Steps and/or TTCN-3 code to reproduce
```
import from A all;
const MyEnumType2 enumX := enumY;// this is allowed as MyEnumtype2 does not contain enumX
testcase clashing_enum_value() runs on ct_empty{
var MyEnumType enumY := enumX; // this is not allowed as enumerated values restrict global names (see clause 6.2.4)
var MyEnumType enumW := enumY;
var MyEnumType enumZ;
enumZ := enumX; // allowed as MyEnumType does not contain enumZ and also, enumX resolves to domain element of type MyEnumType
//enumZ := modules.enumX; //ERROR but due to this resolving to local constant enumX, which is the expected behavior
setverdict(pass);
}
```
```
module A {
friend module modules;
type enumerated MyEnumType {enumX, enumY}
type enumerated MyEnumType2 {enumY, enumZ}
}
```
## What is the current bug behavior?
pass
## What is the expected correct behavior?
error
## 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 @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/683Fully unitialized constants are allowed by Titan2023-11-15T09:57:38ZLevente ErősFully unitialized constants are allowed by Titan## Summary
According to Section 10 point d) of the TTCN-3 standard, "The right-hand side of the assignment that initializes a constant shall evaluate to an object that is at least partially initialized."
## Steps and/or TTCN-3 code to ...## Summary
According to Section 10 point d) of the TTCN-3 standard, "The right-hand side of the assignment that initializes a constant shall evaluate to an object that is at least partially initialized."
## Steps and/or TTCN-3 code to reproduce
```
type record myRecord{
integer field1,
charstring field2 optional,
integer field3
}
type record mymultirecord{
myRecord A,
myRecord B
}
type record of integer roi;
testcase partly_init_constants() runs on ct_empty{
const mymultirecord cr := {A := {field1 := 1, field2 := -, field3 := -}, B := -};
const mymultirecord ct := {A := -, B := -}; //should cause an error
const roi iro := {}; //should cause an error
setverdict(pass);
}
```
## What is the current bug behavior?
The test case passes.
## What is the expected correct behavior?
The indicated lines shall cause an error, as those constants are not even partially initialized (they have unbound fields).
## 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/685Referencing null field does not result in error2023-11-15T09:57:33ZLevente ErősReferencing null field does not result in error## Summary
According to point c) of Section 10 of the TTCN-3 standard, referencing a null field value using dot or index notation shall result in an error. Titan however, does not work accordingly.
## Steps and/or TTCN-3 code to reprod...## Summary
According to point c) of Section 10 of the TTCN-3 standard, referencing a null field value using dot or index notation shall result in an error. Titan however, does not work accordingly.
## Steps and/or TTCN-3 code to reproduce
```
type record defrecord{
default f
}
type record of default defvector;
const defrecord cdr := {null}
const defvector cdv := {null, null}
testcase null_field_constant() runs on ct_empty{
log(cdr.f);
log(cdv[0]);
setverdict(pass);
}
```
## What is the current bug behavior?
Test case passes.
## What is the expected correct behavior?
Test case shall run into an error.
## Relevant logs and/or screenshots
2023/Jan/27 06:39:24.007471 USER - null
2023/Jan/27 06:39:24.007533 USER - null
## 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/686@lazy and @fuzzy modifiers are not working properly in Titan2023-11-15T09:57:27ZLevente Erős@lazy and @fuzzy modifiers are not working properly in Titan## Summary
According to Section 11.0 of the TTCN-3 standard a lazy variable shall be evaluated when it is first referenced after its value assignment, and shall keep its value until its next value assignment. A fuzzy variable shall be e...## Summary
According to Section 11.0 of the TTCN-3 standard a lazy variable shall be evaluated when it is first referenced after its value assignment, and shall keep its value until its next value assignment. A fuzzy variable shall be evaluated each time it is referenced after its value assignment. Titan however, evaluates lazy and fuzzy variables right at their value assignments.
## Steps and/or TTCN-3 code to reproduce
```
module variables {
type component ct_empty{}
testcase lazyeval() runs on ct_empty{
var integer i := 5;
var @lazy integer l := i;
i := 6;
if(l==6){setverdict(pass);}else{setverdict(fail);}
i := 7;
if(l==6){setverdict(pass);}else{setverdict(fail);}
var float n := 1.0;
var float d := 0.0;
var @lazy float f := n/d;
//shall not cause error as it's not evaluated
}
testcase fuzzyeval() runs on ct_empty{
var integer i := 5;
var @fuzzy integer l := i;
i := 6;
if(l==6){setverdict(pass);}else{setverdict(fail);}
i := 7;
if(l==7){setverdict(pass);}else{setverdict(fail);}
var @fuzzy integer v_fuzzy := 1;
var integer v_var;
var boolean v_condition := true;
if (v_condition) {
var integer v_local := 0;
v_fuzzy := v_local;
v_local := 10;
}
if(v_fuzzy==10){setverdict(pass);}else{setverdict(fail);}
}
control{
execute(lazyeval());
execute(fuzzyeval());
}
}
```
## What is the current bug behavior?
lazy test case causes error (and would not pass without the division by zero). The fuzzy test case fails too.
## What is the expected correct behavior?
Both test cases shall 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 @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/687initialization of @lazy and @fuzzy variables can be done by functions having ...2023-11-15T09:57:22ZLevente Erősinitialization of @lazy and @fuzzy variables can be done by functions having inout and out parameters## Summary
The condition in the title is not allowed according to Restriction e) in Section 11.1 of the TTCN-3 standard. Titan however, allows this.
## Steps and/or TTCN-3 code to reproduce
```
function noinoutps() return integer{
v...## Summary
The condition in the title is not allowed according to Restriction e) in Section 11.1 of the TTCN-3 standard. Titan however, allows this.
## Steps and/or TTCN-3 code to reproduce
```
function noinoutps() return integer{
var integer i:=2;
var integer j;
inoutps(i,j);
return 2;
}
function inoutps(inout integer i, out integer j) return integer{
j:=i;
i:=3;
return 3;
}
testcase fuzzy_lazy_ass() runs on ct_empty{
var integer i:=2;
var integer j;
var @lazy integer lv;
@try{
lv := inoutps(i,j);
}@catch(msg){
setverdict(pass);
}
var @lazy integer lv2 := noinoutps();
i:=2;
var @fuzzy integer fv;
@try{
fv := inoutps(i,j);
}@catch(msg){
setverdict(pass);
}
var @fuzzy integer fv2 := noinoutps();
}
```
## What is the current bug behavior?
The testcase has a none verdict.
## What is the expected correct behavior?
The testcase shall have a pass verdict (due to the problematic initializations -- with inoutps running into an error). That is, using ```inoutps(i,j)``` for initializing variables lv and fv shall cause an error.
## 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/694Template initialization error2023-11-15T09:57:11ZLenard NagyTemplate initialization error## Summary
Original Titan Forum article:
https://www.eclipse.org/forums/index.php/t/1112705/
## Steps and/or TTCN-3 code to reproduce
[proba.ttcn](/uploads/2ce1c6fbbf9f5d026872aab8755fdd7e/proba.ttcn)
## What is the current bug behav...## Summary
Original Titan Forum article:
https://www.eclipse.org/forums/index.php/t/1112705/
## Steps and/or TTCN-3 code to reproduce
[proba.ttcn](/uploads/2ce1c6fbbf9f5d026872aab8755fdd7e/proba.ttcn)
## What is the current bug behavior?
Compiler crash
## Titan version
8.3.0
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/699Uncompilable generated code2023-11-15T09:57:06ZGábor SzalaiUncompilable generated code## Summary
The TITAN generates uncompilable code from the ASN.1 file
## Steps and/or TTCN-3 code to reproduce
Try to compile the generated code
## What is the current bug behavior?
error: redeclaration of ‘size_t pos’
size_t pos = p...## Summary
The TITAN generates uncompilable code from the ASN.1 file
## Steps and/or TTCN-3 code to reproduce
Try to compile the generated code
## What is the current bug behavior?
error: redeclaration of ‘size_t pos’
size_t pos = p_buf.get_pos();
^~~
error: redeclaration of ‘OER_struct tmp_oer’
OER_struct tmp_oer;
^~~~~~~
## Titan version
Latest
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/700Compilation issue in getter/setter functions2023-11-15T09:57:00ZBotond BaranyiCompilation issue in getter/setter functionsThe 'is_in_getter_scope' and 'is_in_setter_scope' functions don't compile on Alpine Linux.
See https://www.eclipse.org/forums/index.php/t/1113087/The 'is_in_getter_scope' and 'is_in_setter_scope' functions don't compile on Alpine Linux.
See https://www.eclipse.org/forums/index.php/t/1113087/Botond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/701AtNotation issue causing problems in BER and OER decoding2023-11-15T09:56:55ZAdam KnappAtNotation issue causing problems in BER and OER decodingDear Support,
I got an issue while decoding a COER packet encoded by TITAN COER codec.
I attached the sample project to illustrate the issue. The error is:
hello_world.ttcn:211: Dynamic test case error: Unbound left operand of integer c...Dear Support,
I got an issue while decoding a COER packet encoded by TITAN COER codec.
I attached the sample project to illustrate the issue. The error is:
hello_world.ttcn:211: Dynamic test case error: Unbound left operand of integer comparison.
It is linked ASN.1 files provided by IEEE 1609.2, IEEE 1609.2.1 and ETSI 103 759.
Many thanks in advanced for your support,
Best Regards,
Yann Garcia
The issue originates from this forum topic: https://www.eclipse.org/forums/index.php/t/1112887/Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/702integer is not treated as integer: The union type LENGTHTO field must contain...2023-11-15T09:56:50ZGábor Szalaiinteger is not treated as integer: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields## Summary
the
type integer INT1
is not identified as integer
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type union my_attribute_length {
INT1 short_length,
LIN2_BO_LAST extended_length
}
type record my_a...## Summary
the
type integer INT1
is not identified as integer
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type union my_attribute_length {
INT1 short_length,
LIN2_BO_LAST extended_length
}
type record my_attribute {
my_attribute_length attribute_length,
octetstring attribute_value
} with {
variant (attribute_length) "LENGTHTO(attribute_value)"
}
type integer INT1 (0..255) with { variant "FIELDLENGTH(8)" };
type integer LIN2_BO_LAST (0..65535) with { variant "FIELDLENGTH(16), COMP(nosign), BYTEORDER(last)" };
} with {
encode "RAW"
}
```
## What is the current bug behavior?
proba.ttcn:8.6-11.1: error: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields
proba.ttcn:8.6-11.1: error: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields
## What is the expected correct behavior?
no error
## Relevant logs and/or screenshots
The
```
type union my_attribute_length {
integer short_length,
integer extended_length
} with {
variant (short_length) "FIELDLENGTH(8)"
variant (extended_length) "FIELDLENGTH(16), COMP(nosign), BYTEORDER(last)"
}
```
compiled correctly
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://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/604OOP: issues with parameter default values and inheritance2023-05-16T10:56:08ZBotond BaranyiOOP: issues with parameter default values and inheritance## Summary
The code generated for the following TTCN-3 module produces several C++ compilation errors (details below).
## Steps and/or TTCN-3 code to reproduce
```
type component CT { }
type class @trait CommonInterface {
public fu...## Summary
The code generated for the following TTCN-3 module produces several C++ compilation errors (details below).
## Steps and/or TTCN-3 code to reproduce
```
type component CT { }
type class @trait CommonInterface {
public function @abstract f_do_common(charstring p_test/* := "test"*/);
}
type class @abstract Base extends CommonInterface {
public function f_do_common(charstring p_test:="test") {
log("called from Base: "&p_test)
}
}
type class @final Sub extends Base {
public function f_do_common(charstring p_test:="test") {
log("called from Sub: "&p_test);
}
}
testcase tc() runs on CT {
var Sub sub := Sub.create();
sub.f_do_common();
sub.f_do_common("test2");
}
control {
execute(tc())
}
```
## What is the current bug behavior?
There are 3 issues in the generated code:
1. The parameter default values generated for functions 'Base.f_do_common' and 'Sub.f_do_common' have the same name: 'f__do__common_p__test_defval'.
1. The type of the parameter in the 3 'f_do_common' functions are different (wrapper types are generated for parameters with default values in class methods, so they can contain references to class members). Because of this, the 3 'f_do_common' functions are interpreted as different functions by the C++ compiler, which results in 'Sub' being interpreted as an abstract class.
1. Class 'Base' inherits both 'CommonInterface' and the built-in class 'object'. Both of these inherit a separate version of 'CLASS_BASE' in C++. The compiler can't decide which of the reference counter functions ('add_ref' and 'remove_ref') inherited from 'CLASS_BASE' it should call.
## What is the expected correct behavior?
The generated code should compile successfully.
## Relevant logs and/or screenshots
-
## Possible fixes
-
## Titan version
8.2.0
## Platform details (OS type and version)
Ubuntu 20.04.1
/cc @aknappqwtBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/676Shifting and rotation operations are missing for string elements2023-05-16T10:55:10ZGábor SzalaiShifting and rotation operations are missing for string elements## Summary
The generated c++ code can't be compiled
## Steps and/or TTCN-3 code to reproduce
```
module proba {
control{
var octetstring rawRTCM3msg:='112233445566'O
var integer i:=oct2int(rawRTCM3msg[3] << 4);
log(i)
}
}
`...## Summary
The generated c++ code can't be compiled
## Steps and/or TTCN-3 code to reproduce
```
module proba {
control{
var octetstring rawRTCM3msg:='112233445566'O
var integer i:=oct2int(rawRTCM3msg[3] << 4);
log(i)
}
}
```
## What is the current bug behavior?
```
~/proba$ make
/home/ethgasz/TTCNv3/bin/compiler -L \
proba.ttcn - proba.ttcn
Notify: Parsing TTCN-3 module `proba.ttcn'...
Notify: Checking modules...
Notify: Generating code...
Notify: File `proba.cc' was updated.
Notify: 1 file was updated.
touch compile
g++ -c -DLINUX -I/home/ethgasz/TTCNv3/include -Wall -o proba.o proba.cc
proba.cc: In function ‘void proba::module_control_part()’:
proba.cc:44:68: error: no match for ‘operator<<’ (operand types are ‘const OCTETSTRING_ELEMENT’ and ‘int’)
44 | INTEGER i(oct2int((const_cast< const OCTETSTRING&>(rawRTCM3msg)[3] << 4)));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~ ~
| | |
| | int
| const OCTETSTRING_ELEMENT
make: *** [Makefile:148: proba.o] Error 1
```
## What is the expected correct behavior?
Working c++ code or error reported by the TITAN
## Titan version
Latest
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/591OOP: super-constructor call parameters can only be single expressions2023-05-16T10:53:44ZBotond BaranyiOOP: super-constructor call parameters can only be single expressions## Summary
In the current OOP implementation the parameters of a super-constructor call must be so-called 'single expressions' (i.e. a value/template simple enough that it translates to a single value in the C++ code). Structured values...## Summary
In the current OOP implementation the parameters of a super-constructor call must be so-called 'single expressions' (i.e. a value/template simple enough that it translates to a single value in the C++ code). Structured values and most templates require multiple steps to initialize in C++. Normally these steps are performed on a temporary variable of the same type and this temporary is used instead of the value/template.
## Steps and/or TTCN-3 code to reproduce
```
type record Rec {
integer num,
charstring str
}
type record of integer IntList;
type class C1 {
create(Rec p) { }
}
type class C2 extends C1 {
create(): C1( { 10, "abc" } ) { }
}
```
## What is the current bug behavior?
Instead of the record value ( '{ 10, "abc" }' ) the compiler generates a reference to a temporary, that has is not declared or initialized anywhere, resulting in a C++ error in the generated code.
## What is the expected correct behavior?
The temporary should be declared and initialized somewhere, before it is passed to the constructor of C1.
## Relevant logs and/or screenshots
## Possible fixes
Since the base-constructor call happens before anything else in the constructor in C++, it's not possible to declare and initialize these values/templates inside the constructor. Their initialization code could be generated inside a local function, and the function's return value could be used in the base-constructor call instead of temporary variables.
## Titan version
8.1.0
## Platform details (OS type and version)
Ubuntu 20.04
/cc @aknappqwtBotond 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/680OOP: using class method return value as external function parameter2023-05-16T10:53:40ZBotond BaranyiOOP: using class method return value as external function parameterThe use of return values of class methods as actual parameters of external functions is not handled correctly by the compiler.
In the example below a class method returning a template is passed to a parameter expecting a value. This is n...The use of return values of class methods as actual parameters of external functions is not handled correctly by the compiler.
In the example below a class method returning a template is passed to a parameter expecting a value. This is not caught at compile-time, and it causes a C++ compilation error.
```
type record of integer IntList
with {
encode "JSON";
}
external function f_enc_il(in IntList x) return octetstring
with { extension "prototype(convert) encode(JSON)" }
type class ExampleClass {
private template IntList t := { 0, 1, 2, 3 }
public function get_list() return template IntList { return t; }
}
function test() {
var ExampleClass x := ExampleClass.create;
var octetstring res := f_enc_il(x.get_list()); // C++ compilation error
}
```
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyi