titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2021-11-10T08:22:39Zhttps://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/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/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/571OOP: implement @trait classes and multiple inheritance2021-11-10T13:34:05ZBotond BaranyiOOP: implement @trait classes and multiple inheritanceImplement trait classes and multiple inheritance as described in the standard v1.3.1.Implement trait classes and multiple inheritance as described in the standard v1.3.1.Botond BaranyiBotond Baranyi2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/563Custom encoding name with spaces is not compiled2021-11-10T08:22:33ZAdam KnappCustom encoding name with spaces is not compiled## Summary
Originates from the forum: https://www.eclipse.org/forums/index.php/t/1108162/
It is requested to allow the space character in custom encoding names. At the moment, the custom encodings defined by the following regex are all...## Summary
Originates from the forum: https://www.eclipse.org/forums/index.php/t/1108162/
It is requested to allow the space character in custom encoding names. At the moment, the custom encodings defined by the following regex are allowed: `[A-Za-z][A-Za-z0-9_]*`
The standard allows different characters as well, this is a limitation of the compiler.Adam KnappAdam Knapp2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/561Add the commit identifier to the version printout2021-11-23T10:57:02ZAdam KnappAdd the commit identifier to the version printoutCurrently it is not possible to identify the exact source code of the development/ non-release builds.
One solution is to include the commit identifier to the version printout for non-release builds.
It would be good to print it in a s...Currently it is not possible to identify the exact source code of the development/ non-release builds.
One solution is to include the commit identifier to the version printout for non-release builds.
It would be good to print it in a separate line.
Example:
```
compiler -v
TTCN-3 and ASN.1 Compiler for the TTCN-3 Test Executor
Version: 8.0.0
Build date: Jul 14 2021 09:04:20
Compiled with: GCC 7.5.0
Using OpenSSL 1.1.1 11 Sep 2018
Commit id: 935ba6f596
Copyright (c) 2000-2021 Ericsson Telecom AB
```
Or something similar.Adam KnappAdam Knapp2021-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/559HC -s parameter handling2021-11-10T08:22:27ZAdam KnappHC -s parameter handlingIf HC is started with -s parameter on localhost using unix domain socket, this information is lost, but could be sent over and shown by the MC to identify the HC.
Starting HC:
~~~bash
$./titansim -s 6.0.0.208 6.0.0.208 10322
~~~
Curr...If HC is started with -s parameter on localhost using unix domain socket, this information is lost, but could be sent over and shown by the MC to identify the HC.
Starting HC:
~~~bash
$./titansim -s 6.0.0.208 6.0.0.208 10322
~~~
Current MC behavior:
~~~
2021-07-13 14:27:08: MC@toolsserver208: Unix server socket created successfully.
2021-07-13 14:27:08: MC@toolsserver208: Listening on IP address 6.0.0.208 and TCP port 10322.
MC@toolsserver208: New HC connected from 127.0.0.1 [127.0.0.1]. toolsserver208: Linux 4.4.0-130-generic on x86_64.
~~~
Here, the IP address of HC is intentionally is filled with 127.0.0.1, however, this could be replaced by the actual value given in the -s parameter of HC.
Expected MC behavior:
~~~
2021-07-13 14:27:08: MC@toolsserver208: Unix server socket created successfully.
2021-07-13 14:27:08: MC@toolsserver208: Listening on IP address 6.0.0.208 and TCP port 10322.
MC@toolsserver208: New HC connected from 6.0.0.208 [6.0.0.208]. toolsserver208: Linux 4.4.0-130-generic on x86_64.
~~~Adam KnappAdam Knapp2021-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/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/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/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/551[CR] Make INTEGER(BIGNUM *other_value) API public in Titan API2021-11-10T08:22:16ZLenard Nagy[CR] Make INTEGER(BIGNUM *other_value) API public in Titan API## Summary
There's a need from TitanSim to make INTEGER(BIGNUM *other_value) API public in Titan API.
## Steps and/or TTCN-3 code to reproduce
-
## What is the current bug behavior?
The API call is not public
## What is the expecte...## Summary
There's a need from TitanSim to make INTEGER(BIGNUM *other_value) API public in Titan API.
## Steps and/or TTCN-3 code to reproduce
-
## What is the current bug behavior?
The API call is not public
## What is the expected correct behavior?
The API call can be called
## Relevant logs and/or screenshots
-
## Possible fixes
-
## Titan version
8.0.0
## Platform details (OS type and version)
Any
/cc @aknappqwtBotond BaranyiBotond Baranyi2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/581HC error message could be improved2022-05-04T05:31:11ZAsmelash Tsegay GebretsadkanHC error message could be improved## Summary
When a tsp(test suite parameter) is not initialized, but it is used in the TTCN code as default value of a parameter of a function, executing test cases that use the function fails. The error message displayed could be made r...## Summary
When a tsp(test suite parameter) is not initialized, but it is used in the TTCN code as default value of a parameter of a function, executing test cases that use the function fails. The error message displayed could be made richer to easily spot which tsps are causing the issue.
Part of the error message at the moment is: "Assignment of an unbound charstring value.". It does not say which tsp or which line or which function.
## Steps and/or TTCN-3 code to reproduce
- Create a tsp and do not assign default value.
- Create a function that uses the tsp as a default value of one of its parameters.
- Use the function in a TC
- Execute the test case
I have attached a TTCN file and a cfg file for this.
## What is the current bug behavior?
The TC execution fails with DTE before it starts during configuring the HC. The core error message is:
Dynamic test case error: Assignment of an unbound charstring value.
## What is the expected correct behavior?
It would be more helpful if the error message specified (if possible)
- The line number where the problem occurs
- The function where the problem occurs
- The tsp causing the problem
## 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.)
```ttcn3_start: Starting the test suite
spawn /proj/epg-tools/ft/ttcn3/titan/8.1.0-rhel7-gcc5.4.0/64_bit/bin/mctr_cli /workspace/git/easmgeb/Typhon1/sandbox/sandbox.cfg
*************************************************************************
* TTCN-3 Test Executor - Main Controller 2 *
* Version: 8.1.0 *
* Copyright (c) 2000-2021 Ericsson Telecom AB *
* All rights reserved. This program and the accompanying materials *
* are made available under the terms of the Eclipse Public License v2.0 *
* which accompanies this distribution, and is available at *
* https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html *
*************************************************************************
Using configuration file: /workspace/git/easmgeb/Typhon1/sandbox/sandbox.cfg
MC@seroiuts02335: Unix server socket created successfully.
MC@seroiuts02335: Listening on TCP port 32775.
MC2> seroiuts02335.sero.gic.ericsson.se is the default
spawn /workspace/git/easmgeb/Typhon1/.build/sandbox_ttcn seroiuts02335.sero.gic.ericsson.se 32775
TTCN-3 Host Controller (parallel mode), version 8.1.0
MC@seroiuts02335: New HC connected from 10.117.115.90 [10.117.115.90]. seroiuts02335: Linux 3.10.0-1160.42.2.el7.x86_64 on x86_64.
cmtc
MC@seroiuts02335: Downloading configuration file to all HCs.
HC@seroiuts02335: Dynamic test case error: Assignment of an unbound charstring value.
Error: There were errors during configuring HCs.
Error during initialization. Cannot create MTC.
MC2> ttcn3_start: error: the MTC cannot be created.
exit
MC@seroiuts02335: Shutting down session.
MC@seroiuts02335: Shutdown complete.
```
## Possible fixes
(If you can, link to the line of code that might be responsible for the problem)
## Titan version
Titan 8.1.0
## Platform details (OS type and version)
Red Hat Enterprise Linux Server release 7.9 (Maipo)
/cc @aknappqwt
[Testcases_sandbox.ttcn](/uploads/6e5a8cf77d58111332cd6b39c98be67b/Testcases_sandbox.ttcn)
[ttcn_config.cfg](/uploads/69bfd305b8e156245076f2c1b45931b7/ttcn_config.cfg)Botond BaranyiBotond Baranyi2022-05-04https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/554Use of octetstring and bitstring in LENGTHTO (C side)2022-07-07T06:53:47ZAdam KnappUse of octetstring and bitstring in LENGTHTO (C side)## Related forum topic:
https://www.eclipse.org/forums/index.php/m/1842035/
## Request detail
Hello,
I'm currently implementing a NAS encoder based on 3GPP TTCN files. However it specifies length fields as octetstrings, such as Type4Le...## Related forum topic:
https://www.eclipse.org/forums/index.php/m/1842035/
## Request detail
Hello,
I'm currently implementing a NAS encoder based on 3GPP TTCN files. However it specifies length fields as octetstrings, such as Type4Length_Type and Type6Length_Type (which are the typedefs of octetstrings).
For example in the following structure:
~~~
type record ESM_MessageContainer { /* 24.301 cl. 9.9.3.15 */
IEI8_Type iei optional, /* present in case of TLV; omit in case of LV */
Type6Length_Type iel,
octetstring esmPdu /* ESM PDU without NAS security header*/
};
~~~
Here the field 'iel' specifies the length of 'esmPdu'.
But, Titan doesn't allow to use non-integer field in LENGTHTO variant with the following error:
`error: The LENGTHTO field must be an integer or union type instead of 'octetstring'`
Is there any chance to have a fix for this issue (to be able to use octetstring in LENGTHTO) ?Adam KnappAdam Knapp2022-05-04https://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/721Error when generating PER descriptor containing reference to a constant in an...2024-03-27T16:52:57ZBotond BaranyiError when generating PER descriptor containing reference to a constant in another module## Summary
ASN.1 type constraints can contain references to constants, which are generated into the C++ code if these constraints are relevant to PER. If the referenced constant is defined in another ASN.1 module, then the compiler cras...## Summary
ASN.1 type constraints can contain references to constants, which are generated into the C++ code if these constraints are relevant to PER. If the referenced constant is defined in another ASN.1 module, then the compiler crashes with a fatal error.
## Steps and/or TTCN-3 code to reproduce
Imported module:
`objid-val OBJECT IDENTIFIER ::= { itu-t(0) recommendation(0) a(1) b(3) }`
Importing module:
`CharStr ::= CHARACTER STRING ( WITH COMPONENTS { identification ( syntaxes: { abstract objid-val, transfer objid-val } ) } )`
## What is the current bug behavior?
Compiler crashes with a fatal error
## What is the expected correct behavior?
Successful code generation
## Relevant logs and/or screenshots
-
## Possible fixes
Implement Ref_defd::generate_code_const_ref()
## Titan version
10.0.0
## Platform details (OS type and version)
Ubuntu 22.04
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/720PER_ALIGNED is used incorrectly2024-03-19T07:23:14ZCsaba RádulyPER_ALIGNED is used incorrectly## Summary
PER_ALIGNED is used incorrectly in several places
## Steps and/or TTCN-3 code to reproduce
In several places, the expression `(p_options && PER_ALIGNED)` is used. Using logical `&&` with a constant operand is incorrect.
The...## Summary
PER_ALIGNED is used incorrectly in several places
## Steps and/or TTCN-3 code to reproduce
In several places, the expression `(p_options && PER_ALIGNED)` is used. Using logical `&&` with a constant operand is incorrect.
The value of `PER_ALIGNED` is `0x01`, so this expression is true if `p_options` is not zero.
Bitwise `&` was likely intended.
## What is the current bug behavior?
Aligned PER encoding will be used when canonical PER is requested.
## What is the expected correct behavior?
Aligned PER encoding not used when only canonical PER is requested.
## Relevant logs and/or screenshots
-
## Possible fixes
Change `(p_options && PER_ALIGNED)` to `(p_options & PER_ALIGNED)`
```
core/Bitstring.cc:1432
core/Bitstring.cc:1484
core/Charstring.cc:1980
core/Charstring.cc:2333
core/Octetstring.cc:1549
core/Octetstring.cc:1594
core/Universal_charstring.cc:3297
core/Universal_charstring.cc:3371
```
## Titan version
Commit 129c715f0
## Platform details (OS type and version)
Any
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/719PER: extension groups with one field2024-03-27T16:52:57ZBotond BaranyiPER: extension groups with one fieldThe current PER encoder for sequences/sets treats extension groups with one field as if they were single extensions.
Example:
```
Seq ::= SEQUENCE {
...,
f1 BIT STRING (SIZE (1..8)) OPTIONAL,
[[ f2 BIT STRING (SIZE (1..8)) OPTIONA...The current PER encoder for sequences/sets treats extension groups with one field as if they were single extensions.
Example:
```
Seq ::= SEQUENCE {
...,
f1 BIT STRING (SIZE (1..8)) OPTIONAL,
[[ f2 BIT STRING (SIZE (1..8)) OPTIONAL ]]
}
```
In this example f1 needs to be encoded as if it was a field in the sequence, while f2 needs to be encoded as if it was a sequence with one field (including the optional bit). Currently both f1 and f2 are encoded as if they were fields.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/718PER: remove trailing 0 bits from bitstrings2024-03-27T14:41:45ZBotond BaranyiPER: remove trailing 0 bits from bitstringsAccording to the PER standard:
"Where there are no PER-visible constraints and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies the value
shall be encoded with no trailing 0 bits (note that this means that a value with no 1 bits is alw...According to the PER standard:
"Where there are no PER-visible constraints and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies the value
shall be encoded with no trailing 0 bits (note that this means that a value with no 1 bits is always encoded as an empty bit
string).
Where there is a PER-visible constraint and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies (i.e., the bitstring
type is defined with a "NamedBitList"), the value shall be encoded with trailing 0 bits added or removed as necessary to
ensure that the size of the transmitted value is the smallest size capable of carrying this value and satisfies the effective
size constraint."
The current version of the PER encoder does not remove trailing 0 bits in any situation.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyi