titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2024-03-27T16:52:57Zhttps://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/719PER: extension groups with one field2024-03-27T16:52:57ZBotond BaranyiPER: extension groups with one fieldThe current PER encoder for sequences/sets treats extension groups with one field as if they were single extensions.
Example:
```
Seq ::= SEQUENCE {
...,
f1 BIT STRING (SIZE (1..8)) OPTIONAL,
[[ f2 BIT STRING (SIZE (1..8)) OPTIONA...The current PER encoder for sequences/sets treats extension groups with one field as if they were single extensions.
Example:
```
Seq ::= SEQUENCE {
...,
f1 BIT STRING (SIZE (1..8)) OPTIONAL,
[[ f2 BIT STRING (SIZE (1..8)) OPTIONAL ]]
}
```
In this example f1 needs to be encoded as if it was a field in the sequence, while f2 needs to be encoded as if it was a sequence with one field (including the optional bit). Currently both f1 and f2 are encoded as if they were fields.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/718PER: remove trailing 0 bits from bitstrings2024-03-27T14:41:45ZBotond BaranyiPER: remove trailing 0 bits from bitstringsAccording to the PER standard:
"Where there are no PER-visible constraints and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies the value
shall be encoded with no trailing 0 bits (note that this means that a value with no 1 bits is alw...According to the PER standard:
"Where there are no PER-visible constraints and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies the value
shall be encoded with no trailing 0 bits (note that this means that a value with no 1 bits is always encoded as an empty bit
string).
Where there is a PER-visible constraint and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies (i.e., the bitstring
type is defined with a "NamedBitList"), the value shall be encoded with trailing 0 bits added or removed as necessary to
ensure that the size of the transmitted value is the smallest size capable of carrying this value and satisfies the effective
size constraint."
The current version of the PER encoder does not remove trailing 0 bits in any situation.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/717Configurable lib folder for OpenSSL to handle OpenSSL32024-03-19T07:23:19ZAdam KnappConfigurable lib folder for OpenSSL to handle OpenSSL3Depending on the install configuration, OpenSSL3 might use `lib64` folder instead of `lib`. In our Makefiles, `lib` is used. The proposed solution is to introduce a new variable `OPENSSL_LIB_DIR` that can be overwritten in the `Makefile....Depending on the install configuration, OpenSSL3 might use `lib64` folder instead of `lib`. In our Makefiles, `lib` is used. The proposed solution is to introduce a new variable `OPENSSL_LIB_DIR` that can be overwritten in the `Makefile.personal` on demand.Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/720PER_ALIGNED is used incorrectly2024-03-19T07:23:14ZCsaba RádulyPER_ALIGNED is used incorrectly## Summary
PER_ALIGNED is used incorrectly in several places
## Steps and/or TTCN-3 code to reproduce
In several places, the expression `(p_options && PER_ALIGNED)` is used. Using logical `&&` with a constant operand is incorrect.
The...## Summary
PER_ALIGNED is used incorrectly in several places
## Steps and/or TTCN-3 code to reproduce
In several places, the expression `(p_options && PER_ALIGNED)` is used. Using logical `&&` with a constant operand is incorrect.
The value of `PER_ALIGNED` is `0x01`, so this expression is true if `p_options` is not zero.
Bitwise `&` was likely intended.
## What is the current bug behavior?
Aligned PER encoding will be used when canonical PER is requested.
## What is the expected correct behavior?
Aligned PER encoding not used when only canonical PER is requested.
## Relevant logs and/or screenshots
-
## Possible fixes
Change `(p_options && PER_ALIGNED)` to `(p_options & PER_ALIGNED)`
```
core/Bitstring.cc:1432
core/Bitstring.cc:1484
core/Charstring.cc:1980
core/Charstring.cc:2333
core/Octetstring.cc:1549
core/Octetstring.cc:1594
core/Universal_charstring.cc:3297
core/Universal_charstring.cc:3371
```
## Titan version
Commit 129c715f0
## Platform details (OS type and version)
Any
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/695Selective code splitting2024-03-14T12:30:48ZGábor SzalaiSelective code splittingInitial request:
The compiler generates a large .cc files for some ASN.1 files with lot of type definition.
To limit the g++ memory usage the generated code can be split to more than one files. But usually, the splitting is not required ...Initial request:
The compiler generates a large .cc files for some ASN.1 files with lot of type definition.
To limit the g++ memory usage the generated code can be split to more than one files. But usually, the splitting is not required for all files in the project only just for a few ones.
The selective code splitting can be supported only with Makefile modification.
After further investigation of the requirement, the following specification is proposed:
* Make the -U option (option for code slitting) positing dependent for both makefile_gen and compiler applications
* The ASN.1 or TTCN-3 modules listed after the -U option are splitted according to the specified mode
* Make the -U option compatible with the '-' (selective code generation feature)
* (Modification of TPD handling might be also required)
```
compiler A.ttcn B.ttcn C.asn - A.ttcn -U 2 B.ttcn C.asn //split module B and C into 2
compiler A.ttcn B.ttcn C.asn - -U 2 A.ttcn B.ttcn C.asn //split all modules into 2
compiler A.ttcn B.ttcn C.asn - A.ttcn B.ttcn -U type C.asn //split only module C by types
makefile_gen A.ttcn -U 2 B.ttcn C.asn //split module B and C into 2
makefile_gen A.ttcn B.ttcn -U type C.asn //split only module C by types
```Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/641port type variables and constants are not allowed in Titan2024-02-29T15:52:04ZLevente Erősport type variables and constants are not allowed in Titan## Summary
According to section 6.2.9 of the TTCN-3 standard, port type parameters, variables and constants can be defined. TITAN does not allow this, however.
## Steps and/or TTCN-3 code to reproduce
```
type port mypt message{
ino...## Summary
According to section 6.2.9 of the TTCN-3 standard, port type parameters, variables and constants can be defined. TITAN does not allow this, however.
## Steps and/or TTCN-3 code to reproduce
```
type port mypt message{
inout integer;
}with{extension "internal";}
type component myct2{
port mypt p;
}
type component cct{
port mypt p;
port mypt q;
}
function f_sender(mypt sp) runs on cct{
sp.send(1);
sp.receive;
setverdict(pass);
}
testcase const_port() runs on cct{
connect(self:p, self:p);
connect(self:q, self:q);
const mypt cp := p;
var mypt vp := cp;
const mypt cq := q;
var mypt vq := cq;
f_sender(p);
f_sender(q);
}
```
## What is the current bug behavior?
Compile error
## What is the expected correct behavior?
Pass after execution
## Relevant logs and/or screenshots
```
../src/control_flow.ttcn:139.15-21: error: Constant cannot be defined for port type `@control_flow.mypt2'
../src/control_flow.ttcn:140.13-20: error: Variable cannot be defined for port type `@control_flow.mypt2'
```
## 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/600Enable value list notation for setting values of set types2024-02-28T07:10:02ZAdam KnappEnable value list notation for setting values of set typesCurrently this is explicitly forbidden ("The value list notation for setting values shall not be used for values of set types."), however this behavior was changed in version 4.6.1: "When the value list notation is used for values of set...Currently this is explicitly forbidden ("The value list notation for setting values shall not be used for values of set types."), however this behavior was changed in version 4.6.1: "When the value list notation is used for values of set types, the values are assigned to the fields in the sequential order of the fields in the type definition."Botond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/716ttcn3_logformat different otput format during unmatched text string2024-02-26T13:05:06ZPau Espin Pedrolttcn3_logformat different otput format during unmatched text string## Summary
In "unmatched: First message in the queue does not match the template" log lines, ttcn3_logformat prints output formatted differently:
- As "}\\n,{" in the "got" section
- As "}, {" in the "exp" section.
## Steps and/or TTC...## Summary
In "unmatched: First message in the queue does not match the template" log lines, ttcn3_logformat prints output formatted differently:
- As "}\\n,{" in the "got" section
- As "}, {" in the "exp" section.
## Steps and/or TTCN-3 code to reproduce
Take a long log line printing a "unmatched: First message in the queue does not match the template" case (see log.merged attached). This is basically of the sort "\[...\] with \[...\] format. I run ttcn3_logformat on it. I split manually the text into "got" file, and the text into the "exp" case. I use "meld" difftool to figure out the difference between the received (got) and expected (exp) message. Lot of lines differ, because the text is formatted as "}\\n,{", while the text is formatted as "}, {".
Not sure if the difference is due to "got" vs "exp" sections, or because the "exp" has the AVPs inside a "superset".
## What is the current bug behavior?
Different whitespace formatting is printed by ttcn3_logformat when re-encoding the same line.
## What is the expected correct behavior?
The same format should be applied for whitespace everywhere to make diffing easy.
## Relevant logs and/or screenshots
See attached files:
[exp.txt](/uploads/541d59a1c52b72f365be9bbe7e36d662/exp.txt)
[got.txt](/uploads/89865ab1a2e426b93fb430f46922fe65/got.txt)
[log.merged](/uploads/73eb0a1635c1316c15e9c18a09f33274/log.merged)
[ttcn3_format_output.txt](/uploads/5460e9b274cce8f6a2dc76cbaa7ef18f/ttcn3_format_output.txt)
## Possible fixes
(If you can, link to the line of code that might be responsible for the problem)
## Titan version
```plaintext
$ ttcn3_compiler -v
TTCN-3 and ASN.1 Compiler for the TTCN-3 Test Executor
Version: 9.0.0
Build date: Sep 22 2023 23:38:05
Compiled with: GCC 13.2.1
Using OpenSSL 3.2.1 30 Jan 2024
Commit id: 67573c4
Copyright (c) 2000-2023 Ericsson Telecom AB
```
## Platform details (OS type and version)
Linux.
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/675module renaming does not work2024-02-19T16:35:33ZLevente Erősmodule renaming does not work## Summary
Module renaming does not work as described in Section 8.2.3.1 (EXAMPLE 4 and point i).
## Steps and/or TTCN-3 code to reproduce
In one module different from module D:
```
import from D -> DD all;
```
In module D:
```
mod...## Summary
Module renaming does not work as described in Section 8.2.3.1 (EXAMPLE 4 and point i).
## Steps and/or TTCN-3 code to reproduce
In one module different from module D:
```
import from D -> DD all;
```
In module D:
```
module D {
type integer dint;
}
```
## What is the current bug behavior?
Compilation error.
## What is the expected correct behavior?
Successful build.
## Relevant logs and/or screenshots
```
../src/modules.ttcn:11.15-16: error: at or before token `->': syntax error
```
## 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/639Reactivating defaults and second parameter of deactivate is not working2024-02-15T16:07:49ZLevente ErősReactivating defaults and second parameter of deactivate is not working## Summary
According to the TTCN-3 standard activate() can not only be used with an altstep as actual parameter, but with a default. Also, deactivate can have a second boolean parameter, which if set to true, will reactivate the current...## Summary
According to the TTCN-3 standard activate() can not only be used with an altstep as actual parameter, but with a default. Also, deactivate can have a second boolean parameter, which if set to true, will reactivate the currently deactivated default with the default's priority at deactivation. If false, the default will be activated with highest priority.
## Steps and/or TTCN-3 code to reproduce
```
module control_flow {
type port mypt message{
inout integer;
}with{extension "internal";}
type component myct{
port mypt p;
var integer v;
}
altstep a_myDefaultBehaviour1() runs on myct{
[] p.receive{v:=1}
}
altstep a_myDefaultBehaviour2() runs on myct{
[] p.receive{v:=2}
}
altstep a_myDefaultBehaviour3() runs on myct{
[] p.receive{v:=3}
}
testcase defaults() runs on myct{
connect(self:p, self:p);
var default v_def1 := activate(a_myDefaultBehaviour1());
var default v_def2 := activate(a_myDefaultBehaviour2());
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==3){setverdict(pass);}else{setverdict(fail);}
deactivate(v_def2, true);
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==1){setverdict(pass);}else{setverdict(fail);}
activate(v_def2);
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==2){setverdict(pass);}else{setverdict(fail);}
deactivate(v_def2);
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==1){setverdict(pass);}else{setverdict(fail);}
activate(v_def2);
p.send(1);
p.receive(2); //altsteps will handle as 2 is not sent
if(v==1){setverdict(pass);}else{setverdict(fail);}
}
}
```
## What is the current bug behavior?
There is an error at ```deactivate(v_def2, true);```, as Titan does not expect the second parameter. Also, there is an error at ```activate(v_def2);``` as activate can only be called for altsteps, not defaults, according to TITAN.
## 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 @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/626value list notation for set types is not working2024-02-07T13:47:02ZLevente Erősvalue list notation for set types is not working## Summary
Using value list notation when assigning value to a set type data element results in an error, while according to the TTCN-3 standard, section 6.2.0 it is legal.
## Steps and/or TTCN-3 code to reproduce
```
type set mySet{
...## Summary
Using value list notation when assigning value to a set type data element results in an error, while according to the TTCN-3 standard, section 6.2.0 it is legal.
## Steps and/or TTCN-3 code to reproduce
```
type set mySet{
integer field1,
charstring field2
}
testcase list_notation_set() runs on ct_empty{
var mySet v := {1,"a"};
}
```
Try to compile the above code placed in the module.
## What is the current bug behavior?
Error is produced: Value list notation cannot be used for set type `@datatypes.mySet'
## What is the expected correct behavior?
code should compile as if the assignment was done like:
```
var mySet v := {field1:=1,field2:="a"};
```
## 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 @aknappqwtBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/634inner type unreachable with 2D record of integer2024-02-06T15:31:39ZLevente Erősinner type unreachable with 2D record of integer## Summary
After creating a 2-dimensional integer array type, the innermost type is unreachable with the [-] notation
## Steps and/or TTCN-3 code to reproduce
Use this code in a module:
```
type record length (10) of record length (1...## Summary
After creating a 2-dimensional integer array type, the innermost type is unreachable with the [-] notation
## Steps and/or TTCN-3 code to reproduce
Use this code in a module:
```
type record length (10) of record length (10) of integer Matrix;
type record of integer ROI;
const ROI[-] c := 1;
const Matrix[-][-] c_MyInnermostInt := 1;
```
## What is the current bug behavior?
```ROI[-]``` resolves to integer, but ```Matrix[-][-]``` results in an error
## What is the expected correct behavior?
```Matrix[-][-]``` should resolve to integer.
## 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/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/648Set of compatibility is too restrictive in Titan2024-02-02T17:02:35ZLevente ErősSet of compatibility is too restrictive in Titan## Summary
Set of compatibility should not require type match of set of type, according to Section 6.3.2.3 of the TTCN standard.
## Steps and/or TTCN-3 code to reproduce
```
type record AType {
integer a(0..10) optional,
integer b...## Summary
Set of compatibility should not require type match of set of type, according to Section 6.3.2.3 of the TTCN standard.
## Steps and/or TTCN-3 code to reproduce
```
type record AType {
integer a(0..10) optional,
integer b(0..10) optional,
boolean c
}
type set FType {
integer a optional,
integer b optional,
boolean c
}
type set GType {
integer d optional,
integer e optional,
boolean f
}
testcase set_setof_comp() runs on ct_empty{
var AType v_myVarA := { -, 1, true};
var FType v_myVarF := { a:=1, c:=true };
var GType v_myVarG := { f:=true, d:=7};
v_myVarF := v_myVarG;
//v_myVarF := v_myVarA; error
setverdict(pass);
}
```
## What is the current bug behavior?
Error. See log.
## What is the expected correct behavior?
Assignment ```v_myVarF := v_myVarG;``` is legal, as the fields are compatible.
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:610.15-22: error: Type mismatch: a value of type `@datatypes.FType' was expected instead of `@datatypes.GType'
```
## 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/667Timers cannot be compared to each other, and neither can ports be2024-02-01T09:58:28ZLevente ErősTimers cannot be compared to each other, and neither can ports be## Summary
Comparing ports and timers lead to error.
## Steps and/or TTCN-3 code to reproduce
```
type port pt message{inout integer}with{extension "internal";}
type component oneport{
port pt P
port pt Q
}
testcase compporteq()...## Summary
Comparing ports and timers lead to error.
## Steps and/or TTCN-3 code to reproduce
```
type port pt message{inout integer}with{extension "internal";}
type component oneport{
port pt P
port pt Q
}
testcase compporteq() runs on oneport{
timer t := 0.5;
timer v := 0.5;
if(t!=v){setverdict(pass);}else{setverdict(fail);}
if(P!=Q){setverdict(pass);}else{setverdict(fail);}
if(P==Q){setverdict(pass);}else{setverdict(fail);}
}
```
## What is the current bug behavior?
The above code fails to build (compile error).
## What is the expected correct behavior?
pass
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn: In TTCN-3 module `datatypes':
../src/datatypes.ttcn:757.1-779.1: In testcase definition `compporteq':
../src/datatypes.ttcn:776.3-29: In if statement:
../src/datatypes.ttcn:776.6: error: Reference to a value was expected instead of timer `t'
../src/datatypes.ttcn:777.3-29: In if statement:
../src/datatypes.ttcn:777.6: error: Reference to a value was expected instead of port `@datatypes.oneport.P'
../src/datatypes.ttcn:778.3-29: In if statement:
../src/datatypes.ttcn:778.6: error: Reference to a value was expected instead of port `@datatypes.oneport.P'
```
## 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/653Component type compatibility is too strict in Titan2024-01-25T14:33:18ZLevente ErősComponent type compatibility is too strict in Titan## Summary
Component type compatibility requires exact type match (or the assigned type being the parent of the type of assignee), while section 6.3.3, case 1) of the TTCN-3 standard is more relaxed.
## Steps and/or TTCN-3 code to repr...## Summary
Component type compatibility requires exact type match (or the assigned type being the parent of the type of assignee), while section 6.3.3, case 1) of the TTCN-3 standard is more relaxed.
## Steps and/or TTCN-3 code to reproduce
```
type component ct_empty{}
type port mypt message{
inout integer
}with{extension "internal"}
type component broad{
port mypt P;
port mypt Q;
var integer i:=1;
var integer j:=2;
timer T:=3.0;
}
type component narrow{
port mypt P;
var integer i:=1;
timer T:=3.0;
}
testcase comp_compatibility() runs on empty_ct{
var broad b := broad.create;
var narrow n := narrow.create;
n:=b;
}
```
## What is the current bug behavior?
Compilation fails as n and b are of different types. If the two types are constructed as parent and extension, the assignment works though:
```
type component broad extends narrow{
port mypt Q;
var integer j:=2;
}
type component narrow{
port mypt P;
var integer i:=1;
timer T:=3.0;
}
```
## What is the expected correct behavior?
Compilation should be successful.
## Relevant logs and/or screenshots
``` ../src/assignments.ttcn:559.6: error: Type mismatch: a value of type `@assignments.narrow' was expected instead of `@assignments.broad'
```
## 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/654Runs on compatibility is too strict in Titan2024-01-25T14:32:53ZLevente ErősRuns on compatibility is too strict in Titan## Summary
To start a function on a component A, Titan requires the function to have a runs on clause for A or a parent of A. According to the standard, if the type of the component on which a function is started has all the elements wi...## Summary
To start a function on a component A, Titan requires the function to have a runs on clause for A or a parent of A. According to the standard, if the type of the component on which a function is started has all the elements with the same identifiers, types and restrictions as the runs on type of the function, this means runs on compatibility. This is described in Section 6.3.3, part 2.
## Steps and/or TTCN-3 code to reproduce
```
type port mypt message{
inout integer
}with{extension "internal"}
type component broad{
port mypt P;
port mypt Q;
var integer i:=1;
var integer j:=2;
timer T:=3.0;
}
type component narrow{
port mypt P;
var integer i:=1;
timer T:=3.0;
}
function comp_comp_fn() runs on narrow{
P.receive(1);
i:=2;
P.send(2);
setverdict(pass);
}
testcase comp_comp_runson() runs on broad{
var broad n := broad.create;
connect(self:P,n:P);
n.start(comp_comp_fn());
P.send(1);
P.receive(2);
setverdict(pass);
}
```
## What is the current bug behavior?
Compilation error.
## What is the expected correct behavior?
Should pass. By replacing ```var broad n := broad.create;``` with ```var narrow n := narrow.create;``` it indeed, passes.
## Relevant logs and/or screenshots
```
../src/assignments.ttcn:576.3: error: Component type mismatch: The component reference is of type `@assignments.broad', but function `@assignments.comp_comp_fn' runs on `@assignments.narrow'
```
## 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/710warning: ‘ext_bit’ may be used uninitialized in this function2024-01-23T13:59:30ZGábor Szalaiwarning: ‘ext_bit’ may be used uninitialized in this function## Summary
The PER encoder of the extended enumeration causes c++ warning like:
```
CAP_datatypes_CAPv4.cc: In member function ‘void CAP__datatypes__CAPv4::EventTypeBCSM::PER_encode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int) cons...## Summary
The PER encoder of the extended enumeration causes c++ warning like:
```
CAP_datatypes_CAPv4.cc: In member function ‘void CAP__datatypes__CAPv4::EventTypeBCSM::PER_encode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int) const’:
CAP_datatypes_CAPv4.cc:22640:18: warning: ‘ext_bit’ may be used uninitialized in this function [-Wmaybe-uninitialized]
22640 | p_buf.PER_put_bit(ext_bit);
| ~~~~~~~~~~~~~~~~~^~~~~~~~~
```
## Steps and/or TTCN-3 code to reproduce
Example ASN.1 enum:
```
EventTypeBCSM ::= ENUMERATED {
collectedInfo (2),
analyzedInformation (3),
routeSelectFailure (4),
oCalledPartyBusy (5),
oNoAnswer (6),
oAnswer (7),
oMidCall (8),
oDisconnect (9),
oAbandon (10),
termAttemptAuthorized (12),
tBusy (13),
tNoAnswer (14),
tAnswer (15),
tMidCall (16),
tDisconnect (17),
tAbandon (18),
oTermSeized (19),
callAccepted (27),
oChangeOfPosition (50),
tChangeOfPosition (51),
...,
oServiceChange (52),
tServiceChange (53)
}
```
## What is the current bug behavior?
```
CAP_datatypes_CAPv4.cc: In member function ‘void CAP__datatypes__CAPv4::EventTypeBCSM::PER_encode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int) const’:
CAP_datatypes_CAPv4.cc:22640:18: warning: ‘ext_bit’ may be used uninitialized in this function [-Wmaybe-uninitialized]
22640 | p_buf.PER_put_bit(ext_bit);
| ~~~~~~~~~~~~~~~~~^~~~~~~~~
```
In ext_bit is not initialized if the value is unbound. It doesn't cause run time problem, just compile time warning.
## What is the expected correct behavior?
no warning.
## Possible fixes
Initialize the ext_bit when declared.
## Titan version
10.0.0 & git head
/cc @aknappqwt @mmagyariGábor SzalaiGábor Szalaihttps://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 @mmagyari