titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2023-11-29T10:56:59Zhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/256Concatenation for templates2023-11-29T10:56:59ZEclipse WebmasterConcatenation for templates## Submitted by Gyorgy Rethy
Assigned to **Botond Baranyi**
**[Link to original bug (#512878)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=512878)**
## Description
Concatenation of strings and list/array types is suppo...## Submitted by Gyorgy Rethy
Assigned to **Botond Baranyi**
**[Link to original bug (#512878)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=512878)**
## Description
Concatenation of strings and list/array types is supported for values, but not for templates.
Supporting this language feature will be useful for the users in general, and it is used in 3GPP test suites in particular.
Version: 6.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/362Invoking functions from specific places are not covered with warnings or errors2021-05-05T12:25:41ZEclipse WebmasterInvoking functions from specific places are not covered with warnings or errors## Submitted by Adrien Kirják
**[Link to original bug (#529524)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=529524)**
## Description
See also in TTCN-3 Core Language 16.1.4## Submitted by Adrien Kirják
**[Link to original bug (#529524)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=529524)**
## Description
See also in TTCN-3 Core Language 16.1.4https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/398incorrect error message for useunion attribute2021-05-05T12:32:13ZEclipse Webmasterincorrect error message for useunion attribute## Submitted by Kristof Szabados
**[Link to original bug (#537168)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=537168)**
## Description
For this code:
~~~
type record E22_correct {
enumerated {alt_, alt_1, alt...## Submitted by Kristof Szabados
**[Link to original bug (#537168)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=537168)**
## Description
For this code:
~~~
type record E22_correct {
enumerated {alt_, alt_1, alt_2} xsiType optional,
enumerated {x20, x50_0, small_1} content
}
with {
variant "name as uncapitalized";
variant "element";
variant "useUnion";
}
~~~
the compiler reports "USE-UNION can only be applied to a CHOICE/union type"
But according to B.3.16 of "Part 9: Using XML schema with TTCN-3" it is allowed to apply the useUnion attribute to record types.
Version: 6.4.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/399incorrect code generated by the xsd conversion2021-05-05T12:30:24ZEclipse Webmasterincorrect code generated by the xsd conversion## Submitted by Kristof Szabados
**[Link to original bug (#537169)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=537169)**
## Description
based on this code:
~~~
`<simpleType name="e21unnamed">`
`<union>`
`<sim...## Submitted by Kristof Szabados
**[Link to original bug (#537169)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=537169)**
## Description
based on this code:
~~~
`<simpleType name="e21unnamed">`
`<union>`
`<simpleType>`
<restriction base="float"/>
`</simpleType>`
`<simpleType>`
<restriction base="integer"/>
`</simpleType>`
`<simpleType>`
<restriction base="string"/>
`</simpleType>`
`</union>`
`</simpleType>`
`<element name=" e22">`
`<simpleType>`
<restriction base="ns76:e21unnamed">
<enumeration value="20"/>
<enumeration value="50.0"/>
<enumeration value="small-1"/>
`</restriction>`
`</simpleType>`
`</element>`
~~~
according to the standard the xsdconversion should generate a record something like this to element e22:
~~~
type record E22 {
enumerated {alt_, alt_1, alt_2} xsiType optional,
enumerated {x20, x50_0, small_1} content
}
with {...}
~~~
But instead this code is generated:
~~~
type E21unnamed E22 (
{alt_2:="small-1"},
{alt_:=20.000000},
{alt_:=50.000000}
)
with {
variant "name as ' e22'";
variant "element";
};
~~~
Version: 6.4.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/400titan requires prototype(fast) functions for translation ports2021-05-05T12:46:04ZEclipse Webmastertitan requires prototype(fast) functions for translation ports## Submitted by Kristof Szabados
**[Link to original bug (#537177)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=537177)**
## Description
In it current implementation titan requires function used as translation frunctions...## Submitted by Kristof Szabados
**[Link to original bug (#537177)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=537177)**
## Description
In it current implementation titan requires function used as translation frunctions to have a prototype(fast) attribute.
Otherwise an error is reported:
"
In type mapping:
In `function' mapping:
error: The referenced function `@PortTranslation.char_to_hex' does not have `prototype' fast attribute
"
But the standard does not list such a requirement for the usable functions.
Version: 6.4.0https://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/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.0https://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/545XML namespace issue2022-11-15T10:25:56ZEclipse WebmasterXML namespace issue## Submitted by G??bor Szalai
**[Link to original bug (#572830)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=572830)**
## Description
The xml encoder uses wrong namespaces for imported type
module A defines T1 with name...## Submitted by G??bor Szalai
**[Link to original bug (#572830)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=572830)**
## Description
The xml encoder uses wrong namespaces for imported type
module A defines T1 with namespace nsA
module B defines T2, which has a field type T1, but the B module uses namespace nsB
The T1 typed field is encoded with namespace nsB instead of nsA
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/546Logging objects in Titan/TTCN-32021-06-02T05:47:56ZAdam KnappLogging objects in Titan/TTCN-3Sziasztok,
Belefutottam egy problemaba (lasd cim), amely a mellekelt archivumot, illetve a `Queue.tcQueueLog`-ot futtatva valik lathatova:
(bocs, h nem gyomlaltam ki a nem szigoruan idetartozo reszeket)
~~~
testcase tcQueueLog() runs ...Sziasztok,
Belefutottam egy problemaba (lasd cim), amely a mellekelt archivumot, illetve a `Queue.tcQueueLog`-ot futtatva valik lathatova:
(bocs, h nem gyomlaltam ki a nem szigoruan idetartozo reszeket)
~~~
testcase tcQueueLog() runs on GeneralComp {
var UniversalCharstring uc0, uc1, uc2;
var object v_obj;
log("Create empty queue");
var TitanQueue q := TitanQueue.create();
log(q)
log(q.toString());
uc0 :=UniversalCharstring.create("FirstElement")
q.add(uc0);
uc1 :=UniversalCharstring.create("SecondElement")
q.add(uc1);
uc2 :=UniversalCharstring.create("ThirdElement")
q.add(uc2);
var QueueForwardIterator iterator := q.iterator() => QueueForwardIterator;
while(iterator.hasNext() ){
v_obj := iterator.next() => object;
log ("------>",v_obj)
//log(iterator); //!!!!!!
}
log(q.toString());
log(q); // !!!!!!!
}
~~~
A konstruktor meghivasa utan letrehozott `queue` tipusu objektumot a Titan igy logolja ki `/* log(q) */`
`08:43:36.504041 Queue.ttcn:229 TitanQueue: { Queue: { Collection: { Storable: { } } }, head := null, tail := null }`
Nehany elem hozzaadasa utan viszont a `log(q)` lefagyasztja a Titan-t.
Hasonlokeppen az iterator logolasa is fagyast eredmenyez.
Az objektumon beluli pointer tipusu mezok kozvetlenul nem erhetok el, mivel nem lehetnek publikusak (gondolok itt a head-re es tail-re:
~~~
type class TitanQueue extends Queue {
private var Node head;
private var Node tail;
create() {
head := null;
tail := null;
}
:
:
)
~~~
De barmikor lehet olyan publikus method-ot irni, amivel kiolvashatok,
Pl.
~~~
module TTCN3Queue {
import from TTCN3_standard_collections all;
import from StorableModule all;
import from OODataStructuresCommon all;
type class QueueForwardIterator extends Iterator {
//from head to tail
var Node nextNode;
create(in Node listHead) {
nextNode := listHead;
}
//public function @abstract hasNext() return boolean;
public function hasNext() return boolean {
return nextNode != null;
}
//public function @abstract next() return object;
public function next() return object {
var object toReturn := nextNode.getData();
nextNode := nextNode.getNext();
return toReturn;
}
public function nextN() return Node {
var Node toReturn := nextNode;
nextNode := nextNode.getNext();
return toReturn;
}
}
~~~
Es akkor a kiiratas szinten fagyassal vegzodik:
`Queue.ttcn`
~~~
while(iterator.hasNext() ){
v_obj := iterator.next() => object;
log ("------>",v_obj);
v_node := iterator.nextN() => Node;
log ("+++++++>",v_node);
}
~~~
Ket gondot latok alapvetoen:
- A Titannak semmilyen korulmenyek kozott nem szabad lefagynia
- Masreszt a szabvany semmilyen tampontot nem ad arra nezvest , h hogyan kell es lehet objektumokat logolni
Mint ahogy pl. Pythonban egy print ezt eredmenyezi:
`_main_.Valami object at 0x7ff6a218d2210`
Vagy Java-ban ezt:
`Objektum@512ddf17`
(bar az is hasznos lehetne, ha igyekeznenk az objektum valos tartalmat megjeleniteni).
Mindenesetre a masodik az egy szabvanyositasi kerdes; udvos lenne , ha a tool-ok egysegesen jelenitenek meg az objetumokat.
Gyuri, Kristof, mit gondoltok errol?
UdvBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/555RAW decoding error, hexstring, HEXORDER (high), FIELDORDER(msb)2021-11-10T08:22:18ZGábor SzalaiRAW decoding error, hexstring, HEXORDER (high), FIELDORDER(msb)## Summary
The RAW encoder fails to correctly decode the last digit of hexstring if
- the hexstring is odd number length and length > 2
- and variant "HEXORDER (high)"
- nad variant "FIELDORDER(msb)"
## Steps and/or TTCN-3 code to rep...## Summary
The RAW encoder fails to correctly decode the last digit of hexstring if
- the hexstring is odd number length and length > 2
- and variant "HEXORDER (high)"
- nad variant "FIELDORDER(msb)"
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type record MyRec{
MCC mcc,
bitstring bs length(4)
} with {
variant "FIELDORDER(msb)"
}
type hexstring MCC
with {
variant "FIELDLENGTH (3)";
variant "FIELDORDER(msb)"
variant "HEXORDER (high)";
}
type component CT{}
template MyRec t_hex:={
mcc:='042'H,
bs:='0000'B
}
testcase TChex() runs on CT {
var bitstring bdata:='0000010000100000'B
var MyRec res
var integer i:=decvalue(bdata,res)
log(i)
if(i!=0){
setverdict(fail, "decvalue failed")
} else {
log(res)
if(match(res,t_hex)){
setverdict(pass)
} else {
setverdict(fail, "unmatched value")
}
}
}
control {
execute(TChex())
}
} with { encode "RAW" }
```
## What is the current bug behavior?
`{ mcc := '040'H, bs := '0000'B }`
## What is the expected correct behavior?
`{ mcc := '042'H, bs := '0000'B }`
## Titan version
up to 8.0.0Gábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/556make clean can cause “Argument list too long” error2021-11-10T08:22:21ZAdam Knappmake clean can cause “Argument list too long” error## Summary
In the generated Makefile all files are cleaned in one command
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS) $(GENERATED_HEADERS) \
$(GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES) ...## Summary
In the generated Makefile all files are cleaned in one command
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS) $(GENERATED_HEADERS) \
$(GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES) compile $(DEPFILES) \
tags *.log
```
With a lot of files `Argument list too long` error is got.
## Possible fixes
Separate the clean command, e.g.
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS)
-$(RM) $(GENERATED_HEADERS)
-$(RM) $ (GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES)
-$(RM) compile $(DEPFILES) tags *.log
```
## Titan version
8.0.0.
/cc @aknappqwtAdam KnappAdam Knapp2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/557RAW enc/dec error, hexstring, FILEDORDER(msb), HEXORDER(high), field starts o...2021-11-10T08:22:23ZGábor SzalaiRAW enc/dec error, hexstring, FILEDORDER(msb), HEXORDER(high), field starts on half octet## Summary
The encoding of the hexstring is faulty if:
- FILEDORDER(msb)
- HEXORDER(high)
- The field starts on the half octet
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type record R4{
bitstring f1 length(4),
h...## Summary
The encoding of the hexstring is faulty if:
- FILEDORDER(msb)
- HEXORDER(high)
- The field starts on the half octet
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type record R4{
bitstring f1 length(4),
hexstring f2
} with {
variant (f2) "HEXORDER(high)"
variant "FIELDORDER(msb)"
}
type component CT{}
template bitstring t_expected_encoded:=oct2bit('F123456789'O)
template R4 t_expected_decoded:={'1111'B, '123456789'H }
testcase TC2() runs on CT {
var R4 vl_pdu4:={'1111'B, '123456789'H }
var bitstring vl_encoded:=encvalue(vl_pdu4)
log(vl_pdu4, " encoded as ",bit2oct(vl_encoded), " expected as ", bit2oct(valueof(t_expected_encoded)))
if(match(vl_encoded,t_expected_encoded)){
setverdict(pass)
} else {
setverdict(fail, "wrong encoded value")
}
vl_encoded:=valueof(t_expected_encoded)
var integer vl_res:=decvalue(vl_encoded,vl_pdu4)
log("decode result: ", vl_res)
if(vl_res == 0) {
setverdict(pass)
log(bit2oct(valueof(t_expected_encoded)), " decoded as ",vl_pdu4, " expected as ", t_expected_decoded)
if(match(vl_pdu4,t_expected_decoded)){
setverdict(pass)
} else {
setverdict(fail, "wrong decoded value")
}
} else {
setverdict(fail, "Decoding failed")
}
}
control {
execute(TC2())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
```
15:05:12.936648 proba.ttcn:69 Component type proba.CT was initialized.
15:05:12.937090 proba.ttcn:73 { f1 := '1111'B, f2 := '123456789'H }encoded as 'F315274968'O expected as 'F123456789'O
15:05:12.937457 proba.ttcn:77 setverdict(fail): none -> fail reason: "wrong encoded value", new component reason: "wrong encoded value"
15:05:12.937788 proba.ttcn:83 decode result: 0
15:05:12.938259 proba.ttcn:87 'F123456789'Odecoded as { f1 := '1111'B, f2 := '241638597'H } expected as { f1 := '1111'B, f2 := '123456789'H }
15:05:12.938626 proba.ttcn:91 setverdict(fail): fail -> fail reason: "wrong decoded value", component reason not changed
```
## What is the expected correct behavior?
```
15:08:15.666778 proba.ttcn:73 { f1 := '1111'B, f2 := '123456789'H } encoded as 'F123456789'O expected as 'F123456789'O
15:08:15.667254 proba.ttcn:75 setverdict(pass): none -> pass
15:08:15.667984 proba.ttcn:83 decode result: 0
15:08:15.668373 proba.ttcn:86 setverdict(pass): pass -> pass, component reason not changed
15:08:15.668687 proba.ttcn:87 'F123456789'O decoded as { f1 := '1111'B, f2 := '123456789'H } expected as { f1 := '1111'B, f2 := '123456789'H }
15:08:15.669039 proba.ttcn:89 setverdict(pass): pass -> pass, component reason not changed
```
## Titan version
Up to 8.0.0Gábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/558RAW encdec: overindexing of the buffer2021-11-10T08:22:25ZGábor SzalaiRAW encdec: overindexing of the buffer## Summary
The buffer can be overindexed in the RAW decoder during the decoding of the last field.
## Steps and/or TTCN-3 code to reproduce
Use the test case of the Issue #557
C++ Run the test with valgrind
Java Just run the test cas...## Summary
The buffer can be overindexed in the RAW decoder during the decoding of the last field.
## Steps and/or TTCN-3 code to reproduce
Use the test case of the Issue #557
C++ Run the test with valgrind
Java Just run the test case
## What is the current bug behavior?
C++, Valgrind
```
==13478== Invalid read of size 1
==13478== at 0x17EFE2: TTCN_Buffer::get_byte_align(unsigned long, raw_order_t, raw_order_t, unsigned long) (in /home/ethgasz/proba/a/proba)
==13478== by 0x17F6FD: TTCN_Buffer::get_b(unsigned long, unsigned char*, RAW_coding_par const&, raw_order_t) (in /home/ethgasz/proba/a/proba)
==13478== by 0x1881C2: HEXSTRING::RAW_decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, raw_order_t, bool, int, bool, RAW_Force_Omit const*) (in /home/ethgasz/proba/a/proba)
==13478== by 0x13F2E4: proba::R4::RAW_decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, raw_order_t, bool, int, bool, RAW_Force_Omit const*) (in /home/ethgasz/proba/a/proba)
==13478== by 0x13E9E9: proba::R4::decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, ...) (in /home/ethgasz/proba/a/proba)
==13478== by 0x1531C5: proba::R4_decoder(OCTETSTRING&, proba::R4&, UNIVERSAL_CHARSTRING const&) (in /home/ethgasz/proba/a/proba)
```
Java:
Index overflowGábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/560CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code2021-11-10T08:22:29ZLenard NagyCROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ codeOriginal Bugzilla bug written by Pau Espin Pedrol:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=574469
## Summary
CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code
## Steps and/or TTCN-3 code to reproduce
Following T...Original Bugzilla bug written by Pau Espin Pedrol:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=574469
## Summary
CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code
## Steps and/or TTCN-3 code to reproduce
Following TTCN3 code compiles fine, but generates incorrect C++ code:
~~~
type union PCUIF_ContainerMsgUnion {
octetstring other
} with { variant "" };
type record PCUIF_container {
uint8_t msg_type,
uint8_t spare,
uint16_t len,
PCUIF_ContainerMsgUnion u
} with {
variant (len) "LENGTHTO(u)"
variant (u) "CROSSTAG(
other, OTHERWISE)"
};
~~~
Then when C++ code is compiled:
~~~
g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -I/usr/ttcn3/include -fPIC -o RSL_Emulation.o RSL_Emulation.cc
PCUIF_Types.cc: In member function ‘int PCUIF__Types::PCUIF__container::RAW_decode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int, raw_order_t, boolean, int, boolean, const RAW_Force_Omit*)’:
PCUIF_Types.cc:31342:3: error: ‘else’ without a previous ‘if’
31342 | else selected_field = 0;
| ^~~~
~~~
So it seems the TTCN3->C++ compiler is missing checking specific cases where the union (or the CROSSTAG) has only 1 OTHERWISE option.
Rationale for TTCN3 code shown above:
I wrote that TTCN3 code since I'm implementing the container layer without having yet any specific message in top of it specified, which will come later. Hence I wanted to have some octetstring on top to send random data to test only up to the container layer, while leaving the TTCN3 records prepared to add new container payload data in the future.
## Titan version
6.6.1
/cc @aknappqwtAdam KnappAdam Knapp2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/562xsd2ttcn segfault on Cygwin2021-08-09T11:25:12ZAdam Knappxsd2ttcn segfault on Cygwin## Summary
Running our reg tests on Cygwin, the following test cases in `/titan.core/regression_test/XML/XmlWorkflow/src/xmlTest_Testcases.ttcn` resulted in segmentation fault:
```
tc_decimal_withMinMaxInclusive
tc_decimal_withMinMaxExc...## Summary
Running our reg tests on Cygwin, the following test cases in `/titan.core/regression_test/XML/XmlWorkflow/src/xmlTest_Testcases.ttcn` resulted in segmentation fault:
```
tc_decimal_withMinMaxInclusive
tc_decimal_withMinMaxExclusive
tc_decimal_fractiondigits
tc_ranges_float
```
## Steps and/or TTCN-3 code to reproduce
E.g.:
```bash
$ ~/ttcn3-8.0.0-cygwin3.1.7-gcc10.2.0/bin/xsd2ttcn.exe -p -t XmlTest_decimal_withMinMaxInclusive.xsd
Notify: Checking documents...
Notify: Parsing XML schema document `XmlTest_decimal_withMinMaxInclusive.xsd'...
Notify: Generating TTCN-3 modules...
Segmentation fault (core dumped)
```
## What is the expected correct behavior?
E.g.:
```bash
$ ../../../../Install/bin/xsd2ttcn -p -t XmlTest_decimal_withMinMaxInclusive.xsd
Notify: Checking documents...
Notify: Parsing XML schema document `XmlTest_decimal_withMinMaxInclusive.xsd'...
Notify: Generating TTCN-3 modules...
Notify: File 'www_XmlTest_org_decimal_withMinMaxInclusive.ttcn' was generated.
```
## Titan version
8.0.0
## Platform details (OS type and version)
**Only** Windows10 + Cygwin
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/570Update CONTRIBUTING.md2021-08-17T07:28:41ZLenard NagyUpdate CONTRIBUTING.md## Summary
The CONTRIBUTING.md file contains outdated information
## What is the expected correct behavior?
- Github and git.eclipse.org workflow to be deleted
- Gitlab workflow to be introduced
- Direct link to ECA (https://www.eclip...## Summary
The CONTRIBUTING.md file contains outdated information
## What is the expected correct behavior?
- Github and git.eclipse.org workflow to be deleted
- Gitlab workflow to be introduced
- Direct link to ECA (https://www.eclipse.org/legal/ECA.php) is requested by Eclipse Foundation
## Relevant logs and/or screenshots
https://gitlab.eclipse.org/eclipse/titan/titan.core/-/blob/master/CONTRIBUTING.md
## Titan version
8.0.0
## Platform details (OS type and version)
All
/cc @aknappqwtLenard NagyLenard Nagyhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/572Titan can not handle timers set to more than 25 days2021-11-10T08:22:42ZLenard NagyTitan can not handle timers set to more than 25 days## Summary
Titan can not handle timers set to more than 25 days
## Steps and/or TTCN-3 code to reproduce
Set any timer to more than 2147483 seconds
## What is the current bug behavior?
The too long timer will be set to 2147483 secon...## Summary
Titan can not handle timers set to more than 25 days
## Steps and/or TTCN-3 code to reproduce
Set any timer to more than 2147483 seconds
## What is the current bug behavior?
The too long timer will be set to 2147483 seconds and a Warning is displayed
## What is the expected correct behavior?
The TTCN-3 standard does not specify maximum timeout limit, so any positive float value should be accepted and handled
## Relevant logs and/or screenshots
Warning: The time needed for the first timer expiry is 2.14748e+07 seconds. The operating system does not support such long waiting at once. The maximum time of blocking was set to 2147483 seconds (ca. 24 days).
## Possible fixes
In `void TTCN_Snapshot::take_new(boolean block_execution)`
~~~c
} else {
// issue a warning: the user probably does not want such
// long waiting
TTCN_warning("The time needed for the first timer "
"expiry is %g seconds. The operating system does "
"not support such long waiting at once. The "
"maximum time of blocking was set to %d seconds "
"(ca. %d days).", block_time, MAX_BLOCK_TIME,
MAX_BLOCK_TIME / 86400);
// also modify the the timeout value to get out
// immediately from the while() loop below
timeout = current_time + (double)MAX_BLOCK_TIME;
pollTimeout = MAX_BLOCK_TIME * 1000;
handleTimer = TRUE;
}
~~~
## Titan version
8.0.0
## Platform details (OS type and version)
All
/cc @aknappqwt2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/573Infinite recursion caused by multiple ASN.1 parameterized type instances2021-12-02T07:16:43ZBotond BaranyiInfinite recursion caused by multiple ASN.1 parameterized type instances## Summary
Multiple instances of the same ASN.1 parameterized type in a type hierarchy cause an infinite recursion during semantic analysis.
## ASN.1 code to reproduce
A
DEFINITIONS
AUTOMATIC TAGS
::=
BEGIN
Uint8 ::= INTEGER (0.....## Summary
Multiple instances of the same ASN.1 parameterized type in a type hierarchy cause an infinite recursion during semantic analysis.
## ASN.1 code to reproduce
A
DEFINITIONS
AUTOMATIC TAGS
::=
BEGIN
Uint8 ::= INTEGER (0..255)
ScmsPdu ::= SEQUENCE {
version Uint8 (2),
content CHOICE {
aca-ra AcaRaInterfacePdu,
int INTEGER,
...
}
}
ScmsPdu-Scoped {Pdu} ::= ScmsPdu (WITH COMPONENTS {
...,
content (CONSTRAINED BY {
Pdu
})
})
AcaRaInterfacePdu ::= CHOICE {
a Again,
...
}
Again ::= ScmsPdu-Scoped {
INTEGER
}
END
## What is the current bug behavior?
The compiler crashes due to an infinite recursion.
## What is the expected correct behavior?
Successful semantic analysis.
## Relevant logs and/or screenshots
-
## Possible fixes
-
## Titan version
8.0.0
## Platform details (OS type and version)
Any.Botond BaranyiBotond Baranyi2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/574RAW decoder error: DTE during handling of out of range enum values2021-11-10T08:22:37ZGábor SzalaiRAW decoder error: DTE during handling of out of range enum values## Summary
The RAW decoder of enumerated type can't handle large out of range values. If the decoded value is not fit to int, the decoder throws DTE instead of correct failure code
## Steps and/or TTCN-3 code to reproduce
```
module p...## Summary
The RAW decoder of enumerated type can't handle large out of range values. If the decoded value is not fit to int, the decoder throws DTE instead of correct failure code
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type enumerated my_enum{ a(0), b(1)} with {variant "FIELDLENGTH(32)"}
type union my_union{
my_enum f1,
octetstring f2
}
template my_union t_expected:={f2:='FFFFFFFF'O}
testcase t_1() runs on CT{
var bitstring vl_encoded:='11111111111111111111111111111111'B
var my_union vl_pdu
var integer vl_res:=decvalue(vl_encoded,vl_pdu)
log(vl_res)
log(vl_pdu)
if(vl_res == 0 and match(vl_pdu,t_expected)){
setverdict(pass)
} else {
setverdict(fail)
}
}
control{
execute(t_1())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
Dynamic test case error: Invalid conversion of a large integer value
## What is the expected correct behavior?
pass
## Titan version
Up to 8.0.0
/cc @aknappqwt2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/575RAW encoder: wrong value if FIELDORDER msb with PADDING2021-11-10T08:22:39ZGábor SzalaiRAW encoder: wrong value if FIELDORDER msb with PADDING## Summary
The RAW encoder produces wrong encoded value if the FIELDORDER is msb and padding is used.
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type record my_rec{
bitstring f1 length(6)
} w...## Summary
The RAW encoder produces wrong encoded value if the FIELDORDER is msb and padding is used.
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type record my_rec{
bitstring f1 length(6)
} with {
variant "FIELDORDER(msb)"
variant "PADDING(dword32)"
}
template my_rec t_expected:={f1:='111111'B}
testcase t_1() runs on CT{
var bitstring vl_encoded
var my_rec vl_pdu:={f1:='111111'B}
var integer vl_res
vl_encoded:=encvalue(vl_pdu)
log(vl_encoded)
}
control{
execute(t_1())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
'11000000000000000000000000000000'B
## What is the expected correct behavior?
'11111100000000000000000000000000'B
## Titan version
Up to 8.0.0
/cc @aknappqwt2021-11-09https://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/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/580gcc warning: control reaches end of non-void function2022-05-04T05:39:53ZGábor Szalaigcc warning: control reaches end of non-void function## Summary
The GCC compiler generates a warning:
warning: control reaches end of non-void function [-Wreturn-type]
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type enumerated t_e {I,O}
function f1(in t_e a) return...## Summary
The GCC compiler generates a warning:
warning: control reaches end of non-void function [-Wreturn-type]
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type enumerated t_e {I,O}
function f1(in t_e a) return integer {
select(a){
case (I) {
return 1
}
case else {
return 2
}
}
}
}
```
## What is the current bug behavior?
```
g++ -c -DLINUX -I/home/ethgasz/TTCNv3/include -Wall -o proba.o proba.cc
proba.cc: In function ‘INTEGER proba::f1(const proba::t__e&)’:
proba.cc:665:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
```
## What is the expected correct behavior?
No warning
## Possible fixes
Do not generate the unnecessary goto and label statements
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/582mctr fails to accept all HC connections2022-05-04T05:36:51ZGábor Szalaimctr fails to accept all HC connections## Summary
If a large number of HC try to connect to the mctr, some of them are rejected.
## Steps and/or TTCN-3 code to reproduce
Try to start ~ 30 HCs at the same time.
## What is the current bug behavior?
Some HCs can't connect, ...## Summary
If a large number of HC try to connect to the mctr, some of them are rejected.
## Steps and/or TTCN-3 code to reproduce
Try to start ~ 30 HCs at the same time.
## What is the current bug behavior?
Some HCs can't connect, because the TCP connection is refused
## What is the expected correct behavior?
All HC connects
## Possible fixes
When the mctr opens the listening port, it sets the backlog to 10. When a new connection is accepted, a possible time consuming reverse DNS query is executed. If the number of the waiting connection exceeds 10, the new attempts are rejected by the kernel.
simply increase the backlog. The current value remained unchanged since the beginning.
"If the backlog argument is greater than the value in /proc/sys/net/core/somaxconn, then it is silently capped to that value. Since Linux 5.4, the default in this file is 4096; in earlier kernels, the default value is 128."
So it is safe to increase it to 4096
## Titan version
all
## Platform details (OS type and version)
all
/cc @aknappqwtAdam KnappAdam Knapphttps://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/585XER: untagged optional union decoding error2022-05-04T05:37:14ZBotond BaranyiXER: untagged optional union decoding error## Summary
The XER decoder doesn't move on to the next record/set field if an untagged optional field of union type fails to decode.
Original report: https://www.eclipse.org/forums/index.php/t/1110154/
## Steps and/or TTCN-3 code to r...## Summary
The XER decoder doesn't move on to the next record/set field if an untagged optional field of union type fails to decode.
Original report: https://www.eclipse.org/forums/index.php/t/1110154/
## Steps and/or TTCN-3 code to reproduce
```
module xml {
type record Rec {
integer num,
Uni1 u1 optional,
Uni2 u2
}
type union Uni1 {
charstring x1,
octetstring x2
}
with {
variant "untagged";
}
type union Uni2 {
charstring y1,
octetstring y2
}
with {
variant "untagged";
}
control {
var Rec y; // { 4, omit, { y2 := 'ABCD'O } };
var universal charstring x := "<ns:Rec xmlns:ns='www.somewhere.com/xml2'>\n\t<ns:num>4</ns:num>\n\t<ns:y2>ABCD</ns:y2>\n</ns:Rec>\n\n";
var integer res := decvalue_unichar(x, y);
action(res);
action(y);
}
}
with {
encode "XML";
variant "elementFormQualified";
variant "namespace as 'www.somewhere.com/xml2' prefix 'ns'";
variant "controlNamespace 'http://www.w3.org/2001/XMLSchema-instance' prefix 'xsi'";
}
```
## What is the current bug behavior?
XER decoding error: While XER-decoding type '@xml.Rec': Component 'u1': 'y2' does not match any alternative
## What is the expected correct behavior?
Set the optional union field to 'omit' and continue decoding the next field.
## Relevant logs and/or screenshots
## Possible fixes
Likely something similar to issue #212.
## Titan version
8.1.0
## Platform details (OS type and version)
any
/cc @aknappqwtBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/586Rename UNKNOWN in enum version_t2022-05-04T05:37:56ZAdam KnappRename UNKNOWN in enum version_tversion.h: `enum version_t { UNKNOWN, LEGACY_CRL, LEGACY_CAX, DOT_SEPARATED /*current*/ };`
The `UNKNOWN` literal could be used by other 3rd party component, therefore it should be renamed to something else (e.g. to `UNKNOWN_VERSION_TYP...version.h: `enum version_t { UNKNOWN, LEGACY_CRL, LEGACY_CAX, DOT_SEPARATED /*current*/ };`
The `UNKNOWN` literal could be used by other 3rd party component, therefore it should be renamed to something else (e.g. to `UNKNOWN_VERSION_TYPE`) to mitigate collision.Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/587[CR] Standard change regarding parameters of functions with runs on clause2022-03-26T09:21:21ZLenard Nagy[CR] Standard change regarding parameters of functions with runs on clause## Summary
TTCN-3 standard changed (5.4.1.1 Formal parameters of kind value, _Restrictions_ section)
v4.3.1:
"e) The expression of the default value has to be compatible with the type of the parameter. The expression shall not refer to...## Summary
TTCN-3 standard changed (5.4.1.1 Formal parameters of kind value, _Restrictions_ section)
v4.3.1:
"e) The expression of the default value has to be compatible with the type of the parameter. The expression shall not refer to elements of the component type of the optional runs on clause. The expression shall not refer to other parameters of the same parameter list. The expression shall not contain the invocation of functions with a runs on clause."
vs
v4.13.1:
"e) The expression of formal parameter's default value has to be compatible with the type of the parameter. The expression may be any expression that is well-defined at the beginning of the scope of the parameterized entity, but shall not refer to other parameters of the same parameter list."
## Steps and/or TTCN-3 code to reproduce
```
function f_myFunction( in integer p_par := vc_componentVariable) runs on CompType return Integer {}
type component CompType {
var integer vc_componentVariable := 0;
}
```
## What is the current bug behavior?
The compiler reports error to the example code above:
```Error: default value cannot refer to a template field of the component in the `runs on' clause```
## What is the expected correct behavior?
The compiler should accept the code
## Titan version
8.1.1
## Platform details (OS type and version)
Any
/cc @aknappqwtMiklos MagyariMiklos Magyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/588Implicit omit doesn't work inside optional fields of records/sets2022-05-04T05:38:28ZBotond BaranyiImplicit omit doesn't work inside optional fields of records/sets## Summary
The "implicit omit" extension for optional fields is not applied inside optional fields that are present (i.e. not unbound or omitted).
## Steps and/or TTCN-3 code to reproduce
TTCN module:
```
module test {
type record Em...## Summary
The "implicit omit" extension for optional fields is not applied inside optional fields that are present (i.e. not unbound or omitted).
## Steps and/or TTCN-3 code to reproduce
TTCN module:
```
module test {
type record EmbeddedRecord {
charstring originalField,
charstring newEmbeddedField optional
}
type record Record {
integer int,
charstring newTopLevelField optional,
EmbeddedRecord eRec,
EmbeddedRecord eRec2 optional
}
modulepar Record mp_record with {optional "implicit omit"}
type component MAIN_CT {}
testcase tc_ImplicitOmit() runs on MAIN_CT {
action("mp_record is: ", mp_record);
if(mp_record.newTopLevelField == omit) {
setverdict(pass, "mp_record.newTopLevelField is omit");
} else {
setverdict(fail, "mp_record.newTopLevelField is not omit!");
}
if(mp_record.eRec.newEmbeddedField == omit) {
setverdict(pass, "mp_record.eRec.newEmbeddedField is omit");
} else {
setverdict(fail, "mp_record.eRec.newEmbeddedField is not omit!");
}
if(mp_record.eRec2.newEmbeddedField == omit) {
setverdict(pass, "mp_record.eRec2.newEmbeddedField is omit");
} else {
setverdict(fail, "mp_record.eRec2.newEmbeddedField is not omit!");
}
}
control {
execute(tc_ImplicitOmit());
}
}
```
Configuration file:
```
[MODULE_PARAMETERS]
mp_record := { int := 1, eRec := { originalField := "originalField" }, eRec2 := { originalField := "originalField2" } }
[EXECUTE]
test
```
## What is the current bug behavior?
Field 'mp_record.eRec2.newEmbeddedField' is left unbound. The other optional fields are correctly set to 'omit'.
## What is the expected correct behavior?
Field 'mp_record.eRec2.newEmbeddedField' should be omitted instead of unbound.
## Relevant logs and/or screenshots
## Possible fixes
## 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/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/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/594testcase inout and out parameters do not work properly2022-03-26T12:47:29ZLevente Erőstestcase inout and out parameters do not work properly## Summary
Inconsistency within the TTCN-3 standard that TITAN shall address.
## Steps and/or TTCN-3 code to reproduce
```
module my{
type port mypt message{
inout charstring;
}with{extension "internal";}
type component myct{
va...## Summary
Inconsistency within the TTCN-3 standard that TITAN shall address.
## Steps and/or TTCN-3 code to reproduce
```
module my{
type port mypt message{
inout charstring;
}with{extension "internal";}
type component myct{
var integer v := 0;
port mypt P;
}
altstep myas(integer pii, in integer pi := 1, inout integer pio, out integer po) runs on myct{
[] any port.receive{if(pio==3 and pii==1 and pi == 2){pii := 11; pi := 12; pio := 13; po := 14;log("parameter values in altstep",pii,pi,pio,po);}}
}
function myfn(integer pii, in integer pi, inout integer pio, out integer po) runs on myct{
P.send("1");
alt{
[] myas(pii, pi, pio, po){log("HMOYN EDW!");log("parameter values in function",pii,pi,pio,po);}
}
}
testcase mytc(integer pii, in integer pi, inout integer pio, out integer po) runs on myct{
var myct ptc := myct.create;
connect(mtc:P, ptc:P);
ptc.start(myfn(pii,pi,pio,po));
log("parameter values in testcase",pii,pi,pio,po);
P.receive("1");
P.send("heloka");
ptc.done;
}
testcase passertc() runs on myct{
setverdict(pass);
}
control{
var integer vii := 1;
var integer vi := 2;
var integer vio := 3;
var integer vo := 4;
execute(mytc(vii,vi,vio,vo));
log("variable values",vii,vi,vio,vo);
if(vii==1 and vi==2 and vio==13 and vo==14){
execute(passertc());
}
}
}
```
## What is the current bug behavior?
The new value of out and inout parameters passed to a testcase called from the control part are invisible from the calling scope (control part), which contradicts the low-level description of the behavior of out and inout parameters in the standard.
## What is the expected correct behavior?
At the same time, the current behavior of TITAN agrees the following requirement of the standard: "The test case shall be independent in the sense that it shall be possible to execute the derived executable test case in isolation from other such test cases." There is thus, a contradiction in the standard: If an out or inout parameter of a test case in the control part works properly, and is passed as a parameter to and used by a consecutive test case, this above requirement is not met, while out and inout parameters of the test case work as specified.
Recommendation: Let's make out and inout parameters of test cases work as defined in the standard. At the same time, a warning could be displayed by the compiler and the IDE (maybe even in the runtime log) about the risks of an out or inout formal parameter of a test case if such parameters are used in the code.
## 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/596OOP: update presence checking operators and object methods2022-05-04T05:33:11ZBotond BaranyiOOP: update presence checking operators and object methodsUpdate how presence checking operators (i.e. 'ispresent', 'isbound', 'isvalue' and 'ischosen') work on classes, according to standard version 1.3.1.
Implement the 'equals' method of the 'object' class.
/cc @aknappqwtUpdate how presence checking operators (i.e. 'ispresent', 'isbound', 'isvalue' and 'ischosen') work on classes, according to standard version 1.3.1.
Implement the 'equals' method of the 'object' class.
/cc @aknappqwtBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/597Skip a parameter with default is not working in case of `decvalue`2022-05-04T05:39:02ZAdam KnappSkip a parameter with default is not working in case of `decvalue`## Summary
Skip a parameter with default is not working in case of `decvalue`
## Steps and/or TTCN-3 code to reproduce
`decvalue(b,msg,-,"RAW")`
## What is the current bug behavior?
```error: at or before token `,': syntax error, un...## Summary
Skip a parameter with default is not working in case of `decvalue`
## Steps and/or TTCN-3 code to reproduce
`decvalue(b,msg,-,"RAW")`
## What is the current bug behavior?
```error: at or before token `,': syntax error, unexpected ','```
## What is the expected correct behavior?
Skip a parameter with default. No error message
## Titan version
8.1.0
## Platform details (OS type and version)
all
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/598Missing header files during build2022-05-04T05:36:06ZMiklos MagyariMissing header files during buildWhen running `make dep` or `make`, there are several errors complaining about missing header files.
These are generated header files that are referred to before they are actually created.
For example:
`touch RT2/PreGenRecordOf.cc.compi...When running `make dep` or `make`, there are several errors complaining about missing header files.
These are generated header files that are referred to before they are actually created.
For example:
`touch RT2/PreGenRecordOf.cc.compiled
(dep) RT2/PreGenRecordOf.cc
In file included from RT2/PreGenRecordOf.hh:19,
from RT2/PreGenRecordOf.cc:11:
../core/TTCN3.hh:74:10: fatal error: RT2/TitanLoggerApiSimple.hh: No such file or directory
74 | #include "RT2/TitanLoggerApiSimple.hh"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
(dep) ../core/config_process.tab.cc
In file included from ./RT2/PreGenRecordOf.hh:19,
from ../core/Debugger.hh:21,
from config_process.y:59:
../core/TTCN3.hh:74:10: fatal error: RT2/TitanLoggerApiSimple.hh: No such file or directory
74 | #include "RT2/TitanLoggerApiSimple.hh"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~`Miklos MagyariMiklos Magyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/602address type not handled according to the standars2022-05-10T10:08:34ZLevente Erősaddress type not handled according to the standars## Summary
Port specific address type cannot be specified.
## Steps and/or TTCN-3 code to reproduce
```
type record MyAddressType {
integer field1,
boolean field2
}
type port MyPortType message {
address MyAddressType;
inout i...## Summary
Port specific address type cannot be specified.
## Steps and/or TTCN-3 code to reproduce
```
type record MyAddressType {
integer field1,
boolean field2
}
type port MyPortType message {
address MyAddressType;
inout integer;
}
```
## What is the current bug behavior?
TITAN fails to compile the above code.
## What is the expected correct behavior?
The code should be compiled according to Section 6.2.12, EXAMPLE 2 of the TTCN-3 standard (Core Language)
## Relevant logs and/or screenshots
Error message during compilation:
```
Notify: Parsing TTCN-3 module `../src/my.ttcn'...
../src/my.ttcn:8.3-9: error: at or before token `address': syntax error
Notify: Error found in the input module. Code will not be generated.
make: *** [Makefile:154: compile] Error 1
Operation failed with return value: 2
```
## 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/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/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/609JSON float values2022-07-01T08:28:25ZAdam KnappJSON float values## Summary
JSON decoder can not decode certain float values
## Steps and/or TTCN-3 code to reproduce
Encode a float value, such as `1.23456789e-6`
## What is the current bug behavior?
`While JSON-decoding type ...: Failed to extract...## Summary
JSON decoder can not decode certain float values
## Steps and/or TTCN-3 code to reproduce
Encode a float value, such as `1.23456789e-6`
## What is the current bug behavior?
`While JSON-decoding type ...: Failed to extract valid token, invalid JSON format
Can not decode type ..., because invalid or incomplete message was received`
## What is the expected correct behavior?
Decode the float value properly
## Titan version
8.2.0
## Platform details (OS type and version)
All
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/614Altstep parameterization problem2022-08-22T08:52:25ZLevente ErősAltstep parameterization problem## Summary
TITAN allows activated altstep to have out parameter, while the standard does not.
## Steps and/or TTCN-3 code to reproduce
Create a module with the following content:
```
type port pt_intport message{
inout integer
}wit...## Summary
TITAN allows activated altstep to have out parameter, while the standard does not.
## Steps and/or TTCN-3 code to reproduce
Create a module with the following content:
```
type port pt_intport message{
inout integer
}with{extension "internal"}
type component ct_twointports{
port pt_intport P;
var template integer tv := ?;
}
testcase tc_out_inout_parameters_for_templates_activated_altsteps_1() runs on ct_twointports{ //shall result in error
connect(self:P,self:P);
var default d := activate(as_out_inout_parameters_for_templates_activated_altsteps_1(tv));
P.send(2);
P.receive(1);
if(valueof(tv)==2){setverdict(pass);}
deactivate(d);
}
altstep as_out_inout_parameters_for_templates_activated_altsteps_1(out template integer p) runs on ct_twointports{
[] P.receive(2) {setverdict(pass);p:=2}
}
```
Then compile and execute.
## What is the current bug behavior?
The test case runs and passes. This mean that the out parameter of the activated altstep gets an out value indeed.
## What is the expected correct behavior?
According to clause 5.4.1.2 (b) this shall not work. This means that it should either result in a compilation error or a dynamic test case error. (Note: I don't see any reason why this is logical, but the standars states so.) Also, this should be the result for an inout parameter as well.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.2
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/615Problem with component type template parameter default values2022-08-22T08:47:45ZLevente ErősProblem with component type template parameter default values## Summary
TITAN accepts system as default value for component type template parameter, yet is shouldn't. At the same time, it does not accept self as a default value, while it should.
## Steps and/or TTCN-3 code to reproduce
Create a...## Summary
TITAN accepts system as default value for component type template parameter, yet is shouldn't. At the same time, it does not accept self as a default value, while it should.
## Steps and/or TTCN-3 code to reproduce
Create a TTCN-3 project, and a module in it with the following content:
```
module my{
function fn_def_component_params(template ct_empty cp := system){}
}
```
This should not be able to be compiled. Now change system to self. This should be able to be compiled. Also, if system is changed to mtc or null, that should be able to be compiled too. But these latter 2 work as expected.
## What is the current bug behavior?
See above.
## What is the expected correct behavior?
See above.
## 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/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/617function makes out parameter unbound2022-08-22T08:54:07ZLevente Erősfunction makes out parameter unbound## Summary
If a variable is passed as out parameter to a function, the function renders the variable unbound even if the function does not assign a new value to the variable.
## Steps and/or TTCN-3 code to reproduce
Create a module wi...## Summary
If a variable is passed as out parameter to a function, the function renders the variable unbound even if the function does not assign a new value to the variable.
## Steps and/or TTCN-3 code to reproduce
Create a module with the following content:
```
function fn_out_parameter_unchanged(out integer po){
}
testcase tc_out_parameter_unchanged() runs on ct_empty{ //shall pass
var integer vo := 2;
fn_out_parameter_unchanged(vo);
if(not isbound(vo)){setverdict(fail);}
//if(vo==2){setverdict(pass);}
}
```
Run the testcase.
## What is the current bug behavior?
vo becomes unbound.
## What is the expected correct behavior?
vo shall stay bound with a value of 2
## 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/618Function with out/inout parameters can be called with parameters received as ...2022-08-22T08:51:35ZLevente ErősFunction with out/inout parameters can be called with parameters received as lazy or fuzzy## Summary
A function A having lazy or fuzzy parameters can call another function B, passing its lazy or fuzzy parameters to B. The problem is that this is not allowed if function B has out or inout parameters. But TITAN allows it (I do...## Summary
A function A having lazy or fuzzy parameters can call another function B, passing its lazy or fuzzy parameters to B. The problem is that this is not allowed if function B has out or inout parameters. But TITAN allows it (I don't see the logic behind this but point k) in section 5.4.2 of the standard states so).
## Steps and/or TTCN-3 code to reproduce
Create a TTCN-3 module, and include this:
```
type component ct_empty{}
function fn_no_passing_lazy_fuzzy_to_inout_out_function(@lazy integer l, @fuzzy integer f){
var integer vo := 1;
var integer vio := 2;
fn_internal_no_passing_lazy_fuzzy_to_inout_out_function(vo,vio,l,f);
if(vo==l and vio==f){setverdict(pass);}
}
function fn_internal_no_passing_lazy_fuzzy_to_inout_out_function(out integer o, inout integer io, integer i1, integer i2){
o := i1;
io := i2;
}
testcase tc_no_passing_lazy_fuzzy_to_inout_out_function() runs on ct_empty{
fn_no_passing_lazy_fuzzy_to_inout_out_function(3,4);
}
```
The compile and run.
## What is the current bug behavior?
Test case passes.
## What is the expected correct behavior?
An error should be received.
## 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/619Lazy and fuzzy variables can be passed to inout and out parameters2022-08-22T08:55:38ZLevente ErősLazy and fuzzy variables can be passed to inout and out parameters## Summary
Passing a lazy or fuzzy variable to an out or inout function parameter does not yield an error, while it should according to paragraph l) of section 5.4.2 of the TTCN-3 standard.
## Steps and/or TTCN-3 code to reproduce
Cre...## Summary
Passing a lazy or fuzzy variable to an out or inout function parameter does not yield an error, while it should according to paragraph l) of section 5.4.2 of the TTCN-3 standard.
## Steps and/or TTCN-3 code to reproduce
Create a TTCN-3 module with the following content:
```
type component ct_empty{}
function fn_no_passing_lazy_fuzzy_variables_to_inout_out(out integer o, inout integer io){
o := 3;
io := 4;
}
testcase tc_no_passing_lazy_fuzzy_variables_to_inout_out() runs on ct_empty{ //should lead to error
var @lazy integer vl := 4;
var @fuzzy integer vf := 5;
fn_no_passing_lazy_fuzzy_variables_to_inout_out(vl, vf);
setverdict(pass);
}
```
Then compile and run.
## What is the current bug behavior?
The code is compiled and runs.
## What is the expected correct behavior?
This should lead to 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 @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/620Subfield of actual inout parameter value can be used as another actual inout ...2022-08-22T08:56:19ZLevente ErősSubfield of actual inout parameter value can be used as another actual inout parameter## Summary
According to section 5.4.2, paragraph m of the TTCN-3 standard, a subfield (or element) of an inout parameter cannot be used as another inout parameter in the same function call. But TITAN allows this.
## Steps and/or TTCN-3...## Summary
According to section 5.4.2, paragraph m of the TTCN-3 standard, a subfield (or element) of an inout parameter cannot be used as another inout parameter in the same function call. But TITAN allows this.
## Steps and/or TTCN-3 code to reproduce
Create a module with
```
type component ct_empty{}
type record myrt{
integer field1,
integer field2
}
function fn_no_subfield_as_inout(inout myrt r, inout integer i){
i := 3;
r := {4,4};
}
testcase tc_no_subfield_as_inout() runs on ct_empty{
var myrt ri := {1,2}
fn_no_subfield_as_inout(ri, ri.field1);
log(ri);
setverdict(pass);
}
```
Then compile and build
## What is the current bug behavior?
It runs and the inout record type parameter gets value {4,4}
## What is the expected correct behavior?
compilation 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 @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/621Two fields of same union type variable can be used of inout parameters of sam...2022-08-22T08:57:14ZLevente ErősTwo fields of same union type variable can be used of inout parameters of same function## Summary
Giving two fields of the same union variable as actual parameters of the same function call shall result in error according to paragraph m) of section 5.4.2 of the TTCN-3 standard. Yet, TITAN allows this.
## Steps and/or TTC...## Summary
Giving two fields of the same union variable as actual parameters of the same function call shall result in error according to paragraph m) of section 5.4.2 of the TTCN-3 standard. Yet, TITAN allows this.
## Steps and/or TTCN-3 code to reproduce
Create module with
```
type component ct_empty{}
type union myun{
integer field1,
integer field2
}
function fn_no_union_fields_as_inout(inout integer i1, inout integer i2){
i1 := 3;
i2 := 4;
}
testcase tc_no_union_fields_as_inout() runs on ct_empty{
var myun ui;
ui.field1 := 1;
ui.field2 := 2;
fn_no_union_fields_as_inout(ui.field1, ui.field2);
log(ui);
setverdict(pass);
}
```
Compile and execute.
## What is the current bug behavior?
Test passes.
## What is the expected correct behavior?
Compilation 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 @aknappqwthttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/622-not_a_number can be assigned as value to float2022-11-15T10:25:53ZLevente Erős-not_a_number can be assigned as value to float## Summary
-not_a_number can be assigned as value to float however, according to section 6.1.0, NOTE 2 of the TTCN-3 standard, this is not allowed.
## Steps and/or TTCN-3 code to reproduce
Put this code into a module, compile, and run...## Summary
-not_a_number can be assigned as value to float however, according to section 6.1.0, NOTE 2 of the TTCN-3 standard, this is not allowed.
## Steps and/or TTCN-3 code to reproduce
Put this code into a module, compile, and run:
```
type component ct_empty{}
testcase special_float_values() runs on ct_empty{
const float cpi := infinity;
const float cmi := -infinity;
const float cnn := not_a_number;
const float cmnn := -not_a_number; //should cause an error, the rest should pass
log(cpi, cmi, cnn, cmnn);
setverdict(pass);
}
```
## What is the current bug behavior?
Test passes
## What is the expected correct behavior?
Test shall lead to error (maybe in compilation phase) due to the 4th value assignment.
## 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 @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/623charstrings can include accented characters2022-11-15T10:25:50ZLevente Erőscharstrings can include accented characters## Summary
TITAN accepts accented characters in charstrings, while it should not.
## Steps and/or TTCN-3 code to reproduce
Use the following code in a TTCN-3 module:
```
type component ct_empty{}
testcase accented_chars_charstring()...## Summary
TITAN accepts accented characters in charstrings, while it should not.
## Steps and/or TTCN-3 code to reproduce
Use the following code in a TTCN-3 module:
```
type component ct_empty{}
testcase accented_chars_charstring() runs on ct_empty{ //should result in error
var charstring ccs := "áéíóú";
setverdict(pass);
}
```
## What is the current bug behavior?
Code is compiled and test passes.
## What is the expected correct behavior?
Code should not even compile.
## 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/624Wrong error message after subtype violation2022-11-15T10:25:47ZLevente ErősWrong error message after subtype violation## Summary
Subtyping bitstring and then violating the subtype does not result in the most accurate error message.
## Steps and/or TTCN-3 code to reproduce
Create a TTCN-3 module with the following contents:
```
type bitstring mybs ('...## Summary
Subtyping bitstring and then violating the subtype does not result in the most accurate error message.
## Steps and/or TTCN-3 code to reproduce
Create a TTCN-3 module with the following contents:
```
type bitstring mybs ('0'B, '1'B);
control{
var mybs mbs := '01'B;
}
```
Build, and regard the error message.
## What is the current bug behavior?
Error message is: '01'B is not a valid value for type `bitstring' which has subtype length(1)
## What is the expected correct behavior?
Error message is: '01'B is not a valid value for type `bitstring' which has subtype ('1'B,'0'B)
The reason is that the subtype in this case was not created with a length restriction (however, the domain of the subtype is eventually the same as if we had defined a length(1) restriction).
## 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/625contradicting string patterns only detected when creating data element2022-08-22T09:13:52ZLevente Erőscontradicting string patterns only detected when creating data element## Summary
If there is a sub-subtype the string pattern of which contradicts that of its parent type (which is a subtype of charstring), this is not detected on type definition level, only when attempting to define a data element with t...## Summary
If there is a sub-subtype the string pattern of which contradicts that of its parent type (which is a subtype of charstring), this is not detected on type definition level, only when attempting to define a data element with the given type
## Steps and/or TTCN-3 code to reproduce
Create module with the following contents:
```
type charstring MyString (pattern "abc*xyz");
type MyString MyString3 (pattern "d*xyz"); //error
testcase patterns_charstrings() runs on ct_empty{
var MyString3 v5 := "daxyz";
}
```
## What is the current bug behavior?
Without the var MyString3 v5 := "daxyz"; line, TITAN runs the code and no error verdict is generated.
## What is the expected correct behavior?
Without the var MyString3 v5 := "daxyz"; line, TITAN should be able to detect that the pattern of MyString3 contradicts the pattern of parent type MyString, and generate a compile time 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 @aknappqwthttps://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/627mixed notation does not work for records and sets2022-08-22T12:13:57ZLevente Erősmixed notation does not work for records and sets## Summary
In TTCN-3 it shall be possible to use mixed notation to assign a value to record, and set type data element. TITAN however, does not allow this.
## Steps and/or TTCN-3 code to reproduce
Create a module, include this in it:
...## Summary
In TTCN-3 it shall be possible to use mixed notation to assign a value to record, and set type data element. TITAN however, does not allow this.
## Steps and/or TTCN-3 code to reproduce
Create a module, include this in it:
```
type set mySet{
integer field1,
charstring field2,
boolean field3,
float field4
}
type record myRecord{
integer field1,
charstring field2,
boolean field3,
float field4
}
testcase mixed_notation_set_record() runs on ct_empty{
var mySet v1:= {1,"a",field4:=2.3,field3:=false};
var myRecord v2 := {1,"a",field3:=false,field4:=2.3};
setverdict(pass);
}
```
Compile it
## What is the current bug behavior?
Two errors are generated, one for the set and one for the record.
## What is the expected correct behavior?
The testcase should pass. Maybe changing the order of field3 and field4 in the assignment of the set value is not allowed in TTCN-3, in case of mixed notation, but this is not specified in the standard. So try it with this code piece too:
```
var mySet v1:= {1,"a",field3:=false,field4:=2.3};
```
## 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/628Fuzzy modifier doesn't work2022-08-22T11:16:01ZLevente ErősFuzzy modifier doesn't work## Summary
TITAN does now know the @fuzzy modifier
## Steps and/or TTCN-3 code to reproduce
Create a module with code
```
type port mypt message{
inout R2
}
type component C{
port mypt p;
}
type record R2 {
integer num,
cha...## Summary
TITAN does now know the @fuzzy modifier
## Steps and/or TTCN-3 code to reproduce
Create a module with code
```
type port mypt message{
inout R2
}
type component C{
port mypt p;
}
type record R2 {
integer num,
charstring str
}
template R2 m_msg := { num := 5, @fuzzy str := testcasename() }
testcase fuzzy_modifier() runs on C {
p.send(m_msg);
}
```
Try to compile.
## What is the current bug behavior?
Error is received: error: at or before token `@fuzzy': syntax error
## What is the expected correct behavior?
The code should build and run, and the sent message should be { num := 5, str := "fuzzy_modifier" }
Although the TTCN-3 standard doesn't seem to explain what the fuzzy modifier is, it seems it can be used in places where the value of a given data element is created in runtime.
## 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/629Possibly wrong error message2022-08-22T13:34:55ZLevente ErősPossibly wrong error message## Summary
TITAN returns an error about an omit field, while the problem is not caused by an omit field as there is no omit field in the code.
## Steps and/or TTCN-3 code to reproduce
Use this code in a module:
```
type record MyType...## Summary
TITAN returns an error about an omit field, while the problem is not caused by an omit field as there is no omit field in the code.
## Steps and/or TTCN-3 code to reproduce
Use this code in a module:
```
type record MyType8
{
integer field1 optional
};
testcase ref_subfield_unbound() runs on ct_empty{
var MyType8 v_rec;
var integer v_rec2 := v_rec.field1; //error
setverdict(pass);
}
```
## What is the current bug behavior?
This error message is displayed in the log:
Using the value of an optional field containing omit.
## What is the expected correct behavior?
This would be more appropriate for an error message:
"Copying an unbound integer value."
This is the message that you get if you remove the optional keyword. The reason for this is that the field is not omitted but unbound.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.2.1
## 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/631over-indexing length constrained array is allowed by TITAN2022-11-15T10:25:44ZLevente Erősover-indexing length constrained array is allowed by TITAN## Summary
A two-dimensional array is created with the length restriction of 10 in both directions. However, setting its 11th (i.e. 12th) element is allowed by TITAN.
## Steps and/or TTCN-3 code to reproduce
Create a module with the f...## Summary
A two-dimensional array is created with the length restriction of 10 in both directions. However, setting its 11th (i.e. 12th) element is allowed by TITAN.
## Steps and/or TTCN-3 code to reproduce
Create a module with the following content:
```
type record length (10) of record length (10) of integer Matrix;
testcase nested_def() runs on ct_empty{
var Matrix w;
w[11][11] := 2;
log(w);
setverdict(pass);
}
```
## What is the current bug behavior?
The code builds and runs
## What is the expected correct behavior?
Error (probably compilation time).
## Relevant logs and/or screenshots
This is the value of w at the end of the testcase:
```
MTC@HUL21014: { <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, { <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, <unbound>, 2 } }
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwtAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/632type qualified enum value causes error2022-08-24T06:38:48ZLevente Erőstype qualified enum value causes error## Summary
If a value of a given enum type is referenced in a type qualified way, TITAN runs into error, however according to Example 2 of section 6.2.4 of the TTCN standard, it should be legal.
## Steps and/or TTCN-3 code to reproduce...## Summary
If a value of a given enum type is referenced in a type qualified way, TITAN runs into error, however according to Example 2 of section 6.2.4 of the TTCN standard, it should be legal.
## Steps and/or TTCN-3 code to reproduce
Create a module with the following content
```
type enumerated e1{A,B,C}
testcase comp_enum() runs on ct_empty{
if(e1.A==B){}
}
```
Compile it
## What is the current bug behavior?
An error is produced
## What is the expected correct behavior?
The code should compile
## 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/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/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/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/637Anytype not working with custom types2022-09-19T09:00:37ZLevente ErősAnytype not working with custom types## Summary
A data type that is defined custom in one module and an imported module or in two imported modules, shall not be reachable through the anytype of the importing module. However if a custom type is only defined in one imported ...## Summary
A data type that is defined custom in one module and an imported module or in two imported modules, shall not be reachable through the anytype of the importing module. However if a custom type is only defined in one imported module, then it should be reachable through the anytype of the importing module.
Titan however works the following way: A custom type is only reachable through anytype if it is defined in the module of reference
## Steps and/or TTCN-3 code to reproduce
Create module with contents:
```
module datatypes {
import from datatypes_clashing all;
type component ct_empty{}
type integer I;
testcase anytype_clashing() runs on ct_empty{
var anytype vi;
vi.I := 1; //should lead to error but does not
}
}with{extension "anytype integer, float, I"}
```
Create this other module as well:
```
module datatypes_clashing {
type float I;
}with{extension "anytype float, I"}
```
Build.
## What is the current bug behavior?
No error is produced.
## What is the expected correct behavior?
The value assignment ```vi.I:=1;``` should lead to an error as I is both defined locally and in an imported module, which means a clash. However, Titan does not take into consideration the imported type definition, only the local.
## 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/638Record ofs and arrays are not compatible2022-09-19T09:01:18ZLevente ErősRecord ofs and arrays are not compatible## Summary
Record of type data elements should be compatible with arrays but Titan does not handle them that way
## Steps and/or TTCN-3 code to reproduce
```
type integer MyArrayType1[3];
type record length (3) of integer MyRecordOfTy...## Summary
Record of type data elements should be compatible with arrays but Titan does not handle them that way
## Steps and/or TTCN-3 code to reproduce
```
type integer MyArrayType1[3];
type record length (3) of integer MyRecordOfType1;
testcase array_recordof() runs on ct_empty{
var MyArrayType1 v_a1:= { 7, 8, 9 };
var MyRecordOfType1 v_r1:= v_a1;
setverdict(pass);
}
```
## What is the current bug behavior?
The second assignment resuls in a type incompatibility error.
## What is the expected correct behavior?
The testcase should pass.
## Relevant logs and/or screenshots
```../src/assignments.ttcn:413.30-33: error: Type mismatch: a value of type `@assignments.MyRecordOfType1' was expected instead of `integer[3]'```
## 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/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/640TITAN does not know address restriction for ports.2022-09-19T09:01:56ZLevente ErősTITAN does not know address restriction for ports.## Summary
TITAN does not know address restriction for ports.
## Steps and/or TTCN-3 code to reproduce
```
type port mypt message{
inout integer;
}with{extension "internal";}
type component myct{
port mypt p;
}
type port mypt2 m...## Summary
TITAN does not know address restriction for ports.
## Steps and/or TTCN-3 code to reproduce
```
type port mypt message{
inout integer;
}with{extension "internal";}
type component myct{
port mypt p;
}
type port mypt2 message{
address myct2;
inout integer;
}with{extension "internal";}
type component myct2{
port mypt2 p;
}
function receiver() runs on myct{
p.receive;
}
testcase port_address_restriction() runs on myct2{
var myct ptc := myct.create();
connect(mtc:p,ptc:p);
p.send(1);
setverdict(pass);
}
```
## What is the current bug behavior?
Code does not compile, as address is an unexpected token.
## What is the expected correct behavior?
Code should not compile, or test execution shall result in error at ```p.send(1);```, as mtc:p (type mypt2) cannot be used to send messages to a test component of type mytc.
## 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/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/642Subtyping with pattern does not work2022-09-21T13:33:48ZLevente ErősSubtyping with pattern does not work## Summary
Titan does not know ```pattern``` as subtyping tool.
## Steps and/or TTCN-3 code to reproduce
```
type MyRecord MyRecordSub5 ({ f2 := "user", f3 := pattern "password|Password" },{ f1 := (1 .. 10), f2 := "User" }) // a valid...## Summary
Titan does not know ```pattern``` as subtyping tool.
## Steps and/or TTCN-3 code to reproduce
```
type MyRecord MyRecordSub5 ({ f2 := "user", f3 := pattern "password|Password" },{ f1 := (1 .. 10), f2 := "User" }) // a valid subtype of MyRecord containing all values which match one of the given
```
## What is the current bug behavior?
compilation error
## What is the expected correct behavior?
this should compile
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:314.51-57: error: at or before token `pattern': syntax error
```
## 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/643list subtyping of anytype does not work2022-09-21T13:25:28ZLevente Erőslist subtyping of anytype does not work## Summary
TITAN does not accept subtyping of anytype using a value list
## Steps and/or TTCN-3 code to reproduce
```
type anytype MyAnySub1 ({ integer := 5 },{ boolean := false },{ bitstring := '0011'B },{ charstring := "mine" },{ My...## Summary
TITAN does not accept subtyping of anytype using a value list
## Steps and/or TTCN-3 code to reproduce
```
type anytype MyAnySub1 ({ integer := 5 },{ boolean := false },{ bitstring := '0011'B },{ charstring := "mine" },{ MyEnum := first }); // a valid subtype of anytype, consisting of 5 values
type MyAnySub1 MyAnySub2 ({ integer := 5 },{ boolean := false },{ bitstring := '0011'B }); // a valid subtype of MyAnySub1, consisting of 3 values
type anytype MyAnySub3 (MyAnySub2,{ octetstring := 'FF'O }); // a valid subtype of anytype, consisting of 4 values, 3 of which are defined
// by referring to MyAnySub2
type MyAnySub1 MyAnySub4 ({ integer := 5 },{ boolean := false },{ MyEnum := second }); // causes an error as { MyEnum := second } is not a value of MyAnySub1
type MyAnySub1 MyAnySub5 (MyAnySub3,{ MyEnum := first }); // causes an error as { octetstring := 'FF'O } (defined via referencing MyAnySub3) is
// not a value of MyAnySub1
```
## What is the current bug behavior?
errors
## What is the expected correct behavior?
successful compilation
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:348.42-61: error: Reference to non-existent field `boolean' in union value for type `@datatypes.anytype'
```
etc
## 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/644Value list subtyping for array does not work2022-09-22T09:26:48ZLevente ErősValue list subtyping for array does not work## Summary
It seems that Titan does not value list subtyping for arrays and their subtypes. The value lists only contain values, not templates.
## Steps and/or TTCN-3 code to reproduce
```
type charstring MyArray[1..2];
type MyArray M...## Summary
It seems that Titan does not value list subtyping for arrays and their subtypes. The value lists only contain values, not templates.
## Steps and/or TTCN-3 code to reproduce
```
type charstring MyArray[1..2];
type MyArray MyArraySub1 ({ "aa", "cc" },{ "bb", "cc" }); // valid subtype of MyArray
type MyArraySub1 MyArraySub2 ({ "aa", "cc" }); // valid subtype of MyArraySub1
```
## What is the current bug behavior?
Compile error.
## What is the expected correct behavior?
MyArraySub1 and MyArraySub2 should be considered legal types.
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:362.6-16: error: Subtype constraints are not applicable to type `charstring[1..2]'
```
## 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/645universal charstring is unconditionally incompatible with charstring2024-01-15T15:18:00ZLevente Erősuniversal charstring is unconditionally incompatible with charstring## Summary
According to 6.3.1 in the standard, a universal charstring can be assigned as value to a charstring iff the former does not include special characters.
## Steps and/or TTCN-3 code to reproduce
```
testcase types_assignments...## Summary
According to 6.3.1 in the standard, a universal charstring can be assigned as value to a charstring iff the former does not include special characters.
## Steps and/or TTCN-3 code to reproduce
```
testcase types_assignments() runs on ct_empty{
v_uc := "a";
v_myCharString := v_uc;
setverdict(pass);
v_uc := "áéíőű";
@try{
v_myCharString := v_uc;
}
@catch(msg){
log(msg);
setverdict(pass);
}
}
```
## What is the current bug behavior?
This does not compile.
## What is the expected correct behavior?
Test case passes.
## Relevant logs and/or screenshots
```../src/assignments.ttcn:527.23-26: error: Type mismatch: a value of type `charstring' was expected instead of `universal charstring'
```
## 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/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/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/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/649Length restrictions of record of and set of can be hacked in Titan2022-09-28T13:59:02ZLevente ErősLength restrictions of record of and set of can be hacked in Titan## Summary
If a length constrained set of or record of data element is given value indirectly, Titan does not detect the length violation.
## Steps and/or TTCN-3 code to reproduce
```
type set of integer ISType;
type set length(2) of ...## Summary
If a length constrained set of or record of data element is given value indirectly, Titan does not detect the length violation.
## Steps and/or TTCN-3 code to reproduce
```
type set of integer ISType;
type set length(2) of integer I2SType;
testcase setof_comp_without_arrays() runs on ct_empty{
var ISType v_myVarI;
var I2SType v_myArrayVar;
v_myVarI := { 3, 4 };
v_myArrayVar := v_myVarI; //this assignment is legal (length 2)
v_myVarI[2] := 5; //left side now has 3 elements
v_myArrayVar := v_myVarI; //and still acn be assigned to the length constrained set of
//v_myArrayVar := { 3, 4, 5 }; //this is an equivalent value assignment, which generates a compilation error.
}
```
## What is the current bug behavior?
Test case runs smoothly.
## What is the expected correct behavior?
error should be generated because of length violation.
## 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/650Union compatibility is more restrictive in Titan than in TTCN-3 standard2022-09-28T14:54:48ZLevente ErősUnion compatibility is more restrictive in Titan than in TTCN-3 standard## Summary
Titan requires type equality of union types, instead of field name and field type level compatibiity of the selected type. See code for details.
## Steps and/or TTCN-3 code to reproduce
```
type union U1 {integer i};
type ...## Summary
Titan requires type equality of union types, instead of field name and field type level compatibiity of the selected type. See code for details.
## Steps and/or TTCN-3 code to reproduce
```
type union U1 {integer i};
type union U2 {integer i, boolean b};
testcase union_comp() runs on ct_empty{
var U1 v_u1 := {i := 1};
var U2 v_u2 := v_u1; //correct as all alternatives of U1 exist in U2, Titan: Error
v_u1:= v_u2; //correct as the alternative i is selected in v_u2 and is compatible to i in U1, Titan: Error
}
```
## What is the current bug behavior?
See above
## What is the expected correct behavior?
Test case should run smoothly.
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:638.10-21: In variable definition `v_u2':
../src/datatypes.ttcn:638.18-21: error: Type mismatch: a value of type `@datatypes.U2' was expected instead of `@datatypes.U1'
../src/datatypes.ttcn:639.3-13: In variable assignment:
../src/datatypes.ttcn:639.10-13: error: Type mismatch: a value of type `@datatypes.U1' was expected instead of `@datatypes.U2'
```
## 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/651Big integer related memory leak2022-11-15T10:25:41ZAdam KnappBig integer related memory leak## Summary
Memory leak was detected during JSON decoding, when the encoded JSON message contains big integer.
## Titan version
8.2.0
## Platform details (OS type and version)
All## Summary
Memory leak was detected during JSON decoding, when the encoded JSON message contains big integer.
## Titan version
8.2.0
## Platform details (OS type and version)
AllAdam KnappAdam Knapphttps://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/655Titan does not check MTC compatibility even in runtime2022-10-06T08:28:57ZLevente ErősTitan does not check MTC compatibility even in runtime## Summary
Compilation and even execution does not fail if a function is called with an mtc clause incompatible with the actual type of the mtc. Also, mtc type compatibility shall be handled as described in Section 6.3.3, part 3 of the ...## Summary
Compilation and even execution does not fail if a function is called with an mtc clause incompatible with the actual type of the mtc. Also, mtc type compatibility shall be handled as described in Section 6.3.3, part 3 of the standard.
## Steps and/or TTCN-3 code to reproduce
```
testcase mtc_comp() runs on ct_empty{
var narrow ptc := narrow.create;
ptc.start(fn_mtc_comp());
all compone`nt.done;
setverdict(pass);
}
function fn_mtc_comp() runs on narrow mtc narrow{
//connect(self:P,mtc:P);
setverdict(pass);
}
```
## What is the current bug behavior?
The above code compiles and passes, while it shall not as empty_ct is incompatible with narrow. With the connect operation it fails, as ct_empty does not have a port P.
## What is the expected correct behavior?
Compilation shall fail.
Beware after correcting as Titan does not handle component type compatibility as described in the standard (see 2 latest tickets by me: https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/654 and https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/653). So after correcting, make sure that this code passes:
```
testcase mtc_comp() runs on broad{
var narrow ptc := narrow.create;
ptc.start(fn_mtc_comp());
all component.done;
setverdict(pass);
}
function fn_mtc_comp() runs on narrow mtc narrow{
connect(self:P,mtc:P);
setverdict(pass);
}
```
Right now this passes, but if the compatibility of the runs on clause of the test case was examined with the mtc clause of the function in compile time (with the current implementation of component compatibility), it would fail. However, it should not as narrow is compatible to broad according to the standard without broad being narrow's extension
## 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/656System component type compatibility is not checked at all by Titan2022-10-06T09:02:02ZLevente ErősSystem component type compatibility is not checked at all by Titan## Summary
A function with a system clause can be started in a context where the component type in the system clause of the test case is incompatible with that in that of the function. This is wrong according to Section 6.3.3, point 4 o...## Summary
A function with a system clause can be started in a context where the component type in the system clause of the test case is incompatible with that in that of the function. This is wrong according to Section 6.3.3, point 4 of the TTCN-3 standard.
## 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 system_comp() runs on broad system ct_empty{
var narrow ptc := narrow.create;
ptc.start(fn_system_comp());
all component.done;
setverdict(pass);
}
function fn_system_comp() runs on narrow system narrow{
connect(self:P,mtc:P);
setverdict(pass);
}
```
## What is the current bug behavior?
The above compiles, and passes.
## What is the expected correct behavior?
Compilation should fail, as system type (defined by the test case) is ct_empty, and the function started in the context created by the test case requires a system of type narrow, which is incompatible with ct_empty. So this compatibility should be checked.
Watch out! After fixing this issue, make sure that the component type compatibility is checked according to Section 6.3.3 of the standard (this is referred to from tickets https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/654, https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/653, and https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/652 as well). After fixing, make sure that the following code does not lead to error, but passes:
```
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 system_comp() runs on broad system broad{
var narrow ptc := narrow.create;
ptc.start(fn_system_comp());
all component.done;
setverdict(pass);
}
function fn_system_comp() runs on narrow system narrow{
connect(self:P,mtc:P);
setverdict(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/657Port type definition, collision of types2022-10-07T12:52:19ZLevente ErősPort type definition, collision of types## Summary
Titan does not differentiate between types in port definition if type and parent type are listed too
## Steps and/or TTCN-3 code to reproduce
```
type integer integeralias (1..10);
type port mypt message{
inout integer, i...## Summary
Titan does not differentiate between types in port definition if type and parent type are listed too
## Steps and/or TTCN-3 code to reproduce
```
type integer integeralias (1..10);
type port mypt message{
inout integer, integeralias;
}with{extension "internal";}
```
## What is the current bug behavior?
This code yields an error, as integer is provided twice in the inout list of the port type.
## What is the expected correct behavior?
integer and integeralias (which can be an alias or a value restricted subtype of integer) should be considered two types
## Relevant logs and/or screenshots
```
../src/control_flow.ttcn:3.1-5.1: In type definition `mypt':
../src/control_flow.ttcn:4.3-29: In `inout' list:
../src/control_flow.ttcn:4.18-29: error: Duplicate incoming message type `integer'
../src/control_flow.ttcn:4.9-15: note: Type `integer' is already listed here
```
## 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/658Ports are not strongly typed in Titan2022-10-10T07:55:33ZLevente ErősPorts are not strongly typed in Titan## Summary
Ports should be strongly typed according to Section 6.3.4 of the TTCN-3 standard.
## Steps and/or TTCN-3 code to reproduce
```
type integer integeralias;
type port mypts message{
inout integer;
}with{extension "internal"...## Summary
Ports should be strongly typed according to Section 6.3.4 of the TTCN-3 standard.
## Steps and/or TTCN-3 code to reproduce
```
type integer integeralias;
type port mypts message{
inout integer;
}with{extension "internal";}
type port myptr message{
inout integeralias;
}with{extension "internal";}
type component synasync{
port mypts AS;
port myptr AR;
}
function comm_comp_f() runs on synasync{
var integer via := 10;
var floatalias vfa := 1.0;
var booleanalias vba := false;
var octetstringalias voa := ''O;
AR.receive(integer:?); //error
setverdict(pass);
}
testcase comm_comp() runs on synasync{
var synasync ptc := synasync.create;
connect(self:S, ptc:R); //error -- incompatible ports
ptc.start(comm_comp_f());
var integeralias via := 1;
AS.send(via);
}
```
## What is the current bug behavior?
Pass
## What is the expected correct behavior?
Error due to the indicated rows. If the connect operation produces an error already, try this slightly modified code for proceeding:
```
type integer integeralias;
type port mypt message{
inout integer, integeralias;
}with{extension "internal";}
type component synasync{
port mypt A;
}
function comm_comp_f() runs on synasync{
var integer via := 10;
var floatalias vfa := 1.0;
var booleanalias vba := false;
var octetstringalias voa := ''O;
A.receive(integer:?); //error
setverdict(pass);
}
testcase comm_comp() runs on synasync{
var synasync ptc := synasync.create;
connect(self:A, ptc:A); //no error -- compatible ports, as both types have inout direction
ptc.start(comm_comp_f());
var integeralias via := 1;
A.send(via);
}
```
This should run into an error at the receive operation as it is expecting an integer but getting an integeralias data element.
Synchronous ports have to have strong type compatibility, but the standard does not specify this exactly, so waiting for answer on this from ETSI.
## 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/659More details should be reported for "dynamic test case error"2022-10-14T12:02:15ZMiklos MagyariMore details should be reported for "dynamic test case error"In the console log several errors are reported like this:
> SYSF_SELF_IMS_CallTerm_MCPTT_emergencyGroupCall_downgrade(49)@TS-04: Dynamic test case error: Using non-selected field nameAddr in a value of union type @SIPmsg_Types.Addr_Unio...In the console log several errors are reported like this:
> SYSF_SELF_IMS_CallTerm_MCPTT_emergencyGroupCall_downgrade(49)@TS-04: Dynamic test case error: Using non-selected field nameAddr in a value of union type @SIPmsg_Types.Addr_Union.
This makes finding the source of the error rather difficult as all details are missing. Titan should be fixed to report a trace, similarly for other error messages:
> SYSF_SELF_IMS_CallTerm_MCPTT_emergencyGroupCall_downgrade(9)@TS-20: EPTF_LGenBase:Warning: f_EPTF_LGenBase_executeFsmCell: Dynamic test case error occured during executing step function refers(IMS_SIP_Call_Functions.f_IMS_SIP_step_generate2xxINVITE) for entity #0 in FSM "fsmCallTerm", current state: "calling", reported event: "IMS_SIP_eventName_mediaOK"". Error message: IMS_TC_CallTerm_Functions.ttcn:282(function:f_IMS_TC_CallTerm_behavior)->EPTF_CLL_Base_Functions.ttcn:512(function:f_EPTF_Base_wait4Shutdown)->EPTF_CLL_RBTScheduler_Functions.ttcn:797(altstep:as_EPTF_SchedulerComp_ActionHandler)->EPTF_CLL_RBTScheduler_Functions.ttcn:701(function:f_EPTF_SchedulerComp_performActions)->EPTF_CLL_LGenBase_EventHandlingFunctions.ttcn:4706(function:f_EPTF_LGenBase_TimerActionHandler)->EPTF_CLL_LGenBase_EventHandlingFunctions.ttcn:4812(function:f_EPTF_LGenBase_privateDispatchEvent)->EPTF_CLL_LGenBase_EventHandlingFunctions.ttcn:4516(function:f_EPTF_LGenBase_checkEvents2Post)->EPTF_CLL_LGenBase_EventHandlingFunctions.ttcn:156(function:f_EPTF_LGenBase_postEvent)->EPTF_CLL_LGenBase_EventHandlingFunctions.ttcn:88(function:f_EPTF_LGenBase_dispatchEvent)->EPTF_CLL_LGenBase_EventHandlingFunctions.ttcn:4778(function:f_EPTF_LGenBase_privateDispatchEvent)->EPTF_CLL_LGenBase_EventHandlingFunctions.ttcn:5137(function:f_EPTF_LGenBase_reportEvent4Fsm)->EPTF_CLL_LGenBase_EventHandlingFunctions.ttcn:5411(function:f_EPTF_LGenBase_executeFsmCell)->IMS_SIP_Call_Functions.ttcn:8687(function:f_IMS_SIP_step_generate2xxINVITE) Dynamic test case error: Index overflow in a value of type @PreGenRecordOf.PREGEN_RECORD_OF_INTEGER: The index is 4, but the value has only 3 elements."https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/660Possible memory leak when component is overloaded2022-10-14T14:13:06ZAdam KnappPossible memory leak when component is overloaded## Summary
There are 3 components defined in the code below: sender, mapper, receiver. If the receiver is overloaded or processes the messages slower than they are generated by the sender, the memory consumption of the mapper starts to ...## Summary
There are 3 components defined in the code below: sender, mapper, receiver. If the receiver is overloaded or processes the messages slower than they are generated by the sender, the memory consumption of the mapper starts to increase and it is not reduced even if there are no message to transmit/receive.
## Steps and/or TTCN-3 code to reproduce
```
module MemoryUsage_InternalPorts {
type component MAIN_CT {}
type component PTC_CT {
port Internal_PT internal_PCO;
port Internal_PT incoming_PCO; // used only by the Mapper
port Internal_PT outgoing_PCO; // used only by the Mapper
}
type port Internal_PT message {
inout MSG
} with {extension "internal"}
type record MSG {
charstring addressx,
integer portx,
octetstring msg
}
const charstring c_messageBase := "Very important long message";
function f_sender() runs on PTC_CT {
var charstring vl_message := c_messageBase;
for(var integer i := 0; i < 10; i := i + 1) {
vl_message := vl_message & vl_message;
}
log("Message length: ", lengthof(vl_message));
var MSG vl_msg := { "whatever", 10000, char2oct(vl_message) }
for(var integer i := 0; i < 10*1000*1000; i := i + 1) {
internal_PCO.send(vl_msg);
}
log("====================================================================================================");
log("Sender component is done. Check the memory usage of the TITAN components, then press CTRL+c to stop.");
timer t_wait; t_wait.start(2147482.0); t_wait.timeout;
}
function f_receiver() runs on PTC_CT {
var MSG vl_msg;
var charstring vl_messageStr;
alt {
[] internal_PCO.receive(MSG:?) -> value vl_msg {
// some processing just to use CPU cycles
vl_messageStr := oct2char(vl_msg.msg);
for(var integer i := 0; i < lengthof(c_messageBase); i := i + 1) {
if(vl_messageStr[i] != c_messageBase[i]) {
log("oh, this is not good");
}
}
repeat;
}
}
}
function f_mapper() runs on PTC_CT {
var MSG vl_msg;
alt {
[] incoming_PCO.receive(MSG:?) -> value vl_msg {
outgoing_PCO.send(vl_msg);
repeat;
}
}
}
testcase tc_MemoryUsage_InternalPorts_SenderAndReceiver() runs on MAIN_CT {
var PTC_CT senderPTC := PTC_CT.create("Sender component");
var PTC_CT receiverPTC := PTC_CT.create("Receiver component");
connect(senderPTC:internal_PCO, receiverPTC:internal_PCO);
senderPTC.start(f_sender());
receiverPTC.start(f_receiver());
any component.done;
}
testcase tc_MemoryUsage_InternalPorts_SenderAndMapperAndReceiver() runs on MAIN_CT {
var PTC_CT senderPTC := PTC_CT.create("Sender component");
var PTC_CT mapperPTC := PTC_CT.create("Mapper component");
var PTC_CT receiverPTC := PTC_CT.create("Receiver component");
connect(senderPTC:internal_PCO, mapperPTC:incoming_PCO);
connect(mapperPTC:outgoing_PCO, receiverPTC:internal_PCO);
senderPTC.start(f_sender());
mapperPTC.start(f_mapper());
receiverPTC.start(f_receiver());
any component.done;
}
control {
execute(tc_MemoryUsage_InternalPorts_SenderAndMapperAndReceiver());
}
}
```
Recommended to use the following flags in the config file:
```
FileMask := ERROR | WARNING | PARALLEL | USER
ConsoleMask := ERROR | WARNING | USER
```
The memory usage is monitored by `top`.
## What is the current bug behavior?
When the CPU load is over 100%, the component (its process) starts to consume memory. Probably, the unsent/unprocessed messages start to pile up, however, the allocated memory never will be freed.
It is not clear that this behavior is intentional or it is a bug.
## What is the expected correct behavior?
Somehow free up the memory if it is not used anymore.
## Titan version
8.2.0
## Platform details (OS type and version)
Ubuntu 18 (but probably other platforms are also affected)
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/662Compilation error: undefined reference to symbol 'pthread_setname_np@@GLIBC_2...2022-11-15T10:26:26ZGábor SzalaiCompilation error: undefined reference to symbol 'pthread_setname_np@@GLIBC_2.12'## Summary
The opensource build of the TITAN can't be compiled
## Steps and/or TTCN-3 code to reproduce
make
## What is the current bug behavior?
undefined reference to symbol 'pthread_setname_np@@GLIBC_2.12'
## What is the expecte...## Summary
The opensource build of the TITAN can't be compiled
## Steps and/or TTCN-3 code to reproduce
make
## What is the current bug behavior?
undefined reference to symbol 'pthread_setname_np@@GLIBC_2.12'
## What is the expected correct behavior?
successfull compilation
## Possible fixes
The -lpthread is missing from the LINUX_LIBS, add it to the line 80 of the core/Makefile
## Titan version
from commit de0bf8b259904dcb3fb5f3d3bbabe97ad8ddcbef
## Platform details (OS type and version)
(OS type/distribution and version, e.g. Ubuntu 18.04, Windows 10+Cygwin)
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/663OOP: classes inheritance in reverse order2022-11-15T10:26:00ZBotond BaranyiOOP: classes inheritance in reverse orderTypes in TTCN-3 can be declared in any order. A structured type can be declared before any of its field types or its element type.
The same does not work for classes and their superclasses and supertraits. Declaring a subclass before its...Types in TTCN-3 can be declared in any order. A structured type can be declared before any of its field types or its element type.
The same does not work for classes and their superclasses and supertraits. Declaring a subclass before its superclass or its supertraits causes a C++ compilation error in the generated code.
For example:
```
type class C2 extends C1 {
public var charstring @property p2;
}
type class C1 {
private var integer v;
public var integer @property p;
public function f(in integer x) return integer { return x; }
}
```
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/664OOP: assignment notation in the class 'create' operation2022-11-15T10:25:58ZBotond BaranyiOOP: assignment notation in the class 'create' operationThe 'create' operation for classes only allows value list notation in its actual parameter list. Assignment notation does not work.
For example:
```
type class C1 {
private var integer v;
public var integer @property p;
public fun...The 'create' operation for classes only allows value list notation in its actual parameter list. Assignment notation does not work.
For example:
```
type class C1 {
private var integer v;
public var integer @property p;
public function f(in integer x) return integer { return x; }
}
...
var C1 x1 := C1.create(1, 2); // value list notation, works
var C1 x2 := C1.create(v := 1, p := 2); // assignment notation, causes a compilation error
```
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/665TItan cannot concatenate arrays2022-10-25T08:02:15ZLevente ErősTItan cannot concatenate arrays## Summary
Arrays should be able to be concatenated using the & operator, according to section 7.1.2 of the standard. Titan does not support this.
## Steps and/or TTCN-3 code to reproduce
```
module operators {
type component ct_empt...## Summary
Arrays should be able to be concatenated using the & operator, according to section 7.1.2 of the standard. Titan does not support this.
## Steps and/or TTCN-3 code to reproduce
```
module operators {
type component ct_empty{}
type record of integer roi;
testcase alloperators() runs on ct_empty{
var integer va1[2] := {1,2};
var integer va2[2] := {3,4};
var integer va3[2] := {5,6};
if(va1&va2&va3=={1,2,3,4,5,6}){setverdict(pass);}else{setverdict(fail);}
}
control{
execute(alloperators());
}
}```
## What is the current bug behavior?
Pass verdict
## What is the expected correct behavior?
Compile error
## Relevant logs and/or screenshots
```../src/operators.ttcn:33.6-8: error: Left operand of operation `&' should be a string, `record of' or `set of' value```
## 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/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/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/668compound type compatibility contradicts standars2023-11-22T07:18:38ZLevente Erőscompound type compatibility contradicts standars## Summary
According to section 7.1.3 of the TTCN-3 standard, "If there is a compound expression on both sides of the comparison operator, they shall both be value list notation expressions where the elements shall be of the same root t...## Summary
According to section 7.1.3 of the TTCN-3 standard, "If there is a compound expression on both sides of the comparison operator, they shall both be value list notation expressions where the elements shall be of the same root type and they shall be compared like record of values with elements of that root type." This doesn't seem to work in Titan.
## Steps and/or TTCN-3 code to reproduce
```
testcase compoundeq() runs on ct_empty{
if({1,2,3}=={1,2,3){setverdict(pass);}else{setverdict(fail);}
}
```
## What is the current bug behavior?
Error
## What is the expected correct behavior?
Pass
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:782.21: 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/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/670Rotate does not work well on partly initialized record ofs, set ofs, and arrays2023-11-20T07:32:34ZLevente ErősRotate does not work well on partly initialized record ofs, set ofs, and arrays## Summary
According to Section 7.1.7 of the TTCN-3 standard, "When the rotate operator is used for record of-s, set of-s and arrays, its left hand operand shall be at least partially initialized." However, it does not work, only with f...## Summary
According to Section 7.1.7 of the TTCN-3 standard, "When the rotate operator is used for record of-s, set of-s and arrays, its left hand operand shall be at least partially initialized." However, it does not work, only with fully initialized data elements.
## Steps and/or TTCN-3 code to reproduce
```
type record of integer ROI;
type set of integer SOI;
testcase rotatopsub() runs on ct_empty{
var integer uiarray[3], rot_uiarray[3];
uiarray[0] := 1;
uiarray[2] := 3;
var ROI uiro, rot_uiro;
uiro[0] := 1;
uiro[2] := 3;
var SOI uiso, rot_uiso;
uiso[0] := 1;
uiso[2] := 3;
rot_uiarray := uiarray @> 2;
rot_uiro := uiro @> 2;
rot_uiso := uiso @> 2;
/* if(rot_uiarray[0].isbound){setverdict(pass);}else{setverdict(fail);}
if(rot_uiro[0].isbound){setverdict(pass);}else{setverdict(fail);}
if(rot_uiso[0].isbound){setverdict(pass);}else{setverdict(fail);}
*/
}
```
## What is the current bug behavior?
Runtime error, and after uncommenting the last 3 rows, compile error.
## What is the expected correct behavior?
Pass.
## Relevant logs and/or screenshots
```
MTC@HUL21014: Dynamic test case error: Assignment of an unbound integer value.
```
## 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/671isvalue yields error for non-chosen field, while it should return false2023-11-20T07:33:07ZLevente Erősisvalue yields error for non-chosen field, while it should return false## Summary
According to Section 7.1.8.4, EXAMPLE 3, isvalue should yield false if its parameter is a non-chosen (sub)field of a union. Titan however, returns an error because of the referenced field not being the chosen one.
## Steps a...## Summary
According to Section 7.1.8.4, EXAMPLE 3, isvalue should yield false if its parameter is a non-chosen (sub)field of a union. Titan however, returns an error because of the referenced field not being the chosen one.
## Steps and/or TTCN-3 code to reproduce
```
type union MyUnion_isv {
integer ch1,
integer ch2
}
template MyUnion_isv mw_myUnion := { ch1 := ? }
type record MyRecord_isv {
MyUnion_isv u optional
}
template MyRecord_isv mw_myRecord := { u := mw_myUnion }
testcase isvalue_fun() runs on ct_empty{
var boolean v_checkResult := isvalue(mw_myUnion.ch2); // yields false
if(not v_checkResult){setverdict(pass);}else{setverdict(fail);}
v_checkResult := isvalue(mw_myRecord.u.ch2); // yields false
if(not v_checkResult){setverdict(pass);}else{setverdict(fail);}
v_checkResult := isvalue(m_myRecord.u.ch2); // yields false
if(not v_checkResult){setverdict(pass);}else{setverdict(fail);}
}
```
## What is the current bug behavior?
Error.
## What is the expected correct behavior?
Pass.
## Relevant logs and/or screenshots
```
../src/operators.ttcn:353.51-53: error: Reference to inactive field `ch2' in a template of union type `@operators.MyUnion_isv'. The active field is `ch1'.
```
## 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/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/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 Baranyi