titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2024-01-31T17:52:23Zhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/652Titan does not support the open type2024-01-31T17:52:23ZLevente ErősTitan does not support the open type## Summary
Titan does not support the open type (any) as described in
## Steps and/or TTCN-3 code to reproduce
In a TTCN-3 module, insert
```
external function fx_printf(charstring p_format, any p_data);
```
## What is the current ...## Summary
Titan does not support the open type (any) as described in
## Steps and/or TTCN-3 code to reproduce
In a TTCN-3 module, insert
```
external function fx_printf(charstring p_format, any p_data);
```
## What is the current bug behavior?
Titan cannot parse ```any```
## What is the expected correct behavior?
This should be translated in a way that the corresponding function defined in C++ takes a character string as its first parameter and an arbitrary type as its second parameter.
## Relevant logs and/or screenshots
```
../src/exfn.ttcn:3.50-52: error: at or before token `any': syntax error
```
## Possible fixes
The ANY type shall be defined in the Titan framework, which can be arbitrarily used for whatever TTCN-3 type data element is provided as the 2nd actual parameter. Probably architectural planning is needed for this. Let's talk about this some time.
## 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/677inter-language imports allowed from younger language2024-01-11T15:16:52ZLevente Erősinter-language imports allowed from younger language## Summary
According to Section 8.2.3, point c) of the TTCN-3 standard, "the TTCN-3 language specification in an import statement has to be lower or equal to the TTCN-3
language specification of the importing module".
## Steps and/or T...## Summary
According to Section 8.2.3, point c) of the TTCN-3 standard, "the TTCN-3 language specification in an import statement has to be lower or equal to the TTCN-3
language specification of the importing module".
## Steps and/or TTCN-3 code to reproduce
```
module modules language "TTCN-3:2003"{
type component ct_empty{}
import from F language "TTCN-3:2010" all; //ERROR```
testcase oldimport() runs on ct_empty{
var oldint voi := 1;
setverdict(pass);
}
}
```
also
```
module F language "TTCN-3:2010"{
type integer oldint
}
```
## What is the current bug behavior?
Code compiles and passes.
## What is the expected correct behavior?
Compilation or runtime error due to the import language clause being greater than the language clause of module ```modules```.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/647Record compatibility is too restrictive in Titan2023-11-15T09:58:34ZLevente ErősRecord compatibility is too restrictive in Titan## Summary
Record compatibility requires type name equivalence while standard does not.
## Steps and/or TTCN-3 code to reproduce
```
type record AType {
integer a(0..10) optional,
integer b(0..10) optional,
boolean c
}
type reco...## Summary
Record compatibility requires type name equivalence while standard does not.
## Steps and/or TTCN-3 code to reproduce
```
type record AType {
integer a(0..10) optional,
integer b(0..10) optional,
boolean c
}
type record BType {
integer a optional,
integer b(0..10) optional,
boolean c
}
type record CType {
// type with different field names
integer d optional,
integer e optional,
boolean f
}
type record DType {
// type with field c optional
integer a optional,
integer b optional,
boolean c optional
}
type record EType {
// type with an extra field d
integer a optional,
integer b optional,
boolean c,
float d optional
}
testcase record_comp() runs on ct_empty{
var AType v_myVarA := { -, 1, true};
var BType v_myVarB := { omit, 2, true};
var CType v_myVarC := { 3, omit, true};
v_myVarA := v_myVarB; //error
v_myVarC := v_myVarB; //error
v_myVarC := { d:= 20 };
v_myVarA := v_myVarC; //error
}
```
## What is the current bug behavior?
Errors in the indicated lines.
## What is the expected correct behavior?
These assignments shall succeed: Titan should only take into consideration the (written form of the) value that is assigned, not its type (and not the field names).
## Relevant logs and/or screenshots
```
../src/datatypes.ttcn:553.3-22: In variable assignment:
../src/datatypes.ttcn:553.15-22: error: Type mismatch: a value of type `@datatypes.AType' was expected instead of `@datatypes.BType'
../src/datatypes.ttcn:554.3-22: In variable assignment:
../src/datatypes.ttcn:554.15-22: error: Type mismatch: a value of type `@datatypes.CType' was expected instead of `@datatypes.BType'
../src/datatypes.ttcn:558.3-22: In variable assignment:
../src/datatypes.ttcn:558.15-22: error: Type mismatch: a value of type `@datatypes.AType' was expected instead of `@datatypes.CType'
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/672default as module parameter type is allowed in Titan2023-11-15T09:58:29ZLevente Erősdefault as module parameter type is allowed in Titan## Summary
According to Section 8.2.1, Restriction b), module parameters shall not be of default type. However, TITAN allows for this.
## Steps and/or TTCN-3 code to reproduce
```
module modules{
type component ct_empty{}
modulepar ...## Summary
According to Section 8.2.1, Restriction b), module parameters shall not be of default type. However, TITAN allows for this.
## Steps and/or TTCN-3 code to reproduce
```
module modules{
type component ct_empty{}
modulepar default d; //wrong
testcase mp_def_val() runs on ct_empty{
log(d);
}
control{
execute(mp_def_val());
}
}
```
## What is the current bug behavior?
unbound default is logged
## What is the expected correct behavior?
compliation error
## Relevant logs and/or screenshots
```
2022/Dec/06 08:57:24.298261 USER - <unbound>
```
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/678importing imports does not work2023-11-15T09:57:56ZLevente Erősimporting imports does not work## Summary
The mechanism defined in Section 8.2.3.7 of the TTCN-3 standard for importing import statements does not work.
## Steps and/or TTCN-3 code to reproduce
In one module
```
import from chain1 {import all};
testcase importimpo...## Summary
The mechanism defined in Section 8.2.3.7 of the TTCN-3 standard for importing import statements does not work.
## Steps and/or TTCN-3 code to reproduce
In one module
```
import from chain1 {import all};
testcase importimport() runs on ct_empty{
// log(chain2const); //ERROR
// log(chain32const); //ERROR
log(chain33const); //should work
}
```
Furthermore the following modules are needed:
```
module chain1 {
private import from chain2 {import all}; //importing module does not see chain2const
import from chain22 {import all}; //importing module does not see chain32const
public import from chain23 {import all}; //importing module does see chain33const
}
```
```
module chain2 {
import from chain3 all;
}
```
```
module chain22 {
import from chain32 all;
}
```
```
module chain23 {
import from chain33 all;
}
```
```
module chain3 {
const integer chain2const := 1;
}
```
```
module chain32 {
const integer chain32const := 1;
}
```
```
module chain33 {
const integer chain33const := 1;
}
```
## What is the current bug behavior?
chain33const is not seen in the main module.
## What is the expected correct behavior?
chain33const shoulw be seen in the main module while the commented-out two constants should not be seen.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/679Titan does not know the alternative notation of the control function2023-11-15T09:57:51ZLevente ErősTitan does not know the alternative notation of the control function## Summary
According to Section 8.3 of the TTCN-3 standard ```control``` is identical to ```function control()``` and also control can have parameters this way and can be called explicitly from another control part with or without param...## Summary
According to Section 8.3 of the TTCN-3 standard ```control``` is identical to ```function control()``` and also control can have parameters this way and can be called explicitly from another control part with or without parameters
## Steps and/or TTCN-3 code to reproduce
In one module:
```
import from modules2 all;
import from modules5 all;
control{
modules2.control; //../src/modules.ttcn:217.12-18: error: syntax error
modules5.control(3); //../src/modules.ttcn:218.12-18: error: syntax error
}
```
In modules2:
```
control{
var integer myvar := 2;
}
```
In modules5:
```
module modules5 {
function control(integer i) return integer{ //../src/modules5.ttcn:3.10-16: error: at or before token `control': syntax error
var integer myvar := i;
return myvar;
}
}
```
## What is the current bug behavior?
Errors, see in comments
## What is the expected correct behavior?
These whould all work.
## 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/681Clashing enumerated identifiers unrecognized by Titan2023-11-15T09:57:46ZLevente ErősClashing enumerated identifiers unrecognized by Titan## Summary
According to sections 6.2.4 and 8.2.3.1 of the TTCN-3 standard, the identifier of a data element with an enumerated type cannot be identical to any element of the domain of the given enumerated type. For example, in the below...## Summary
According to sections 6.2.4 and 8.2.3.1 of the TTCN-3 standard, the identifier of a data element with an enumerated type cannot be identical to any element of the domain of the given enumerated type. For example, in the below example enumY cannot be the identifier of a MyEnumType variable for the following reason: When assigning enumY as the value of another MyEnumType variable enumW, it is ambiguous whether the value of variable enumY (which is enumX) or the emunerated domain value enumY is intended to be assigned to enumW.
## Steps and/or TTCN-3 code to reproduce
```
import from A all;
const MyEnumType2 enumX := enumY;// this is allowed as MyEnumtype2 does not contain enumX
testcase clashing_enum_value() runs on ct_empty{
var MyEnumType enumY := enumX; // this is not allowed as enumerated values restrict global names (see clause 6.2.4)
var MyEnumType enumW := enumY;
var MyEnumType enumZ;
enumZ := enumX; // allowed as MyEnumType does not contain enumZ and also, enumX resolves to domain element of type MyEnumType
//enumZ := modules.enumX; //ERROR but due to this resolving to local constant enumX, which is the expected behavior
setverdict(pass);
}
```
```
module A {
friend module modules;
type enumerated MyEnumType {enumX, enumY}
type enumerated MyEnumType2 {enumY, enumZ}
}
```
## What is the current bug behavior?
pass
## What is the expected correct behavior?
error
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/683Fully unitialized constants are allowed by Titan2023-11-15T09:57:38ZLevente ErősFully unitialized constants are allowed by Titan## Summary
According to Section 10 point d) of the TTCN-3 standard, "The right-hand side of the assignment that initializes a constant shall evaluate to an object that is at least partially initialized."
## Steps and/or TTCN-3 code to ...## Summary
According to Section 10 point d) of the TTCN-3 standard, "The right-hand side of the assignment that initializes a constant shall evaluate to an object that is at least partially initialized."
## Steps and/or TTCN-3 code to reproduce
```
type record myRecord{
integer field1,
charstring field2 optional,
integer field3
}
type record mymultirecord{
myRecord A,
myRecord B
}
type record of integer roi;
testcase partly_init_constants() runs on ct_empty{
const mymultirecord cr := {A := {field1 := 1, field2 := -, field3 := -}, B := -};
const mymultirecord ct := {A := -, B := -}; //should cause an error
const roi iro := {}; //should cause an error
setverdict(pass);
}
```
## What is the current bug behavior?
The test case passes.
## What is the expected correct behavior?
The indicated lines shall cause an error, as those constants are not even partially initialized (they have unbound fields).
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/685Referencing null field does not result in error2023-11-15T09:57:33ZLevente ErősReferencing null field does not result in error## Summary
According to point c) of Section 10 of the TTCN-3 standard, referencing a null field value using dot or index notation shall result in an error. Titan however, does not work accordingly.
## Steps and/or TTCN-3 code to reprod...## Summary
According to point c) of Section 10 of the TTCN-3 standard, referencing a null field value using dot or index notation shall result in an error. Titan however, does not work accordingly.
## Steps and/or TTCN-3 code to reproduce
```
type record defrecord{
default f
}
type record of default defvector;
const defrecord cdr := {null}
const defvector cdv := {null, null}
testcase null_field_constant() runs on ct_empty{
log(cdr.f);
log(cdv[0]);
setverdict(pass);
}
```
## What is the current bug behavior?
Test case passes.
## What is the expected correct behavior?
Test case shall run into an error.
## Relevant logs and/or screenshots
2023/Jan/27 06:39:24.007471 USER - null
2023/Jan/27 06:39:24.007533 USER - null
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/686@lazy and @fuzzy modifiers are not working properly in Titan2023-11-15T09:57:27ZLevente Erős@lazy and @fuzzy modifiers are not working properly in Titan## Summary
According to Section 11.0 of the TTCN-3 standard a lazy variable shall be evaluated when it is first referenced after its value assignment, and shall keep its value until its next value assignment. A fuzzy variable shall be e...## Summary
According to Section 11.0 of the TTCN-3 standard a lazy variable shall be evaluated when it is first referenced after its value assignment, and shall keep its value until its next value assignment. A fuzzy variable shall be evaluated each time it is referenced after its value assignment. Titan however, evaluates lazy and fuzzy variables right at their value assignments.
## Steps and/or TTCN-3 code to reproduce
```
module variables {
type component ct_empty{}
testcase lazyeval() runs on ct_empty{
var integer i := 5;
var @lazy integer l := i;
i := 6;
if(l==6){setverdict(pass);}else{setverdict(fail);}
i := 7;
if(l==6){setverdict(pass);}else{setverdict(fail);}
var float n := 1.0;
var float d := 0.0;
var @lazy float f := n/d;
//shall not cause error as it's not evaluated
}
testcase fuzzyeval() runs on ct_empty{
var integer i := 5;
var @fuzzy integer l := i;
i := 6;
if(l==6){setverdict(pass);}else{setverdict(fail);}
i := 7;
if(l==7){setverdict(pass);}else{setverdict(fail);}
var @fuzzy integer v_fuzzy := 1;
var integer v_var;
var boolean v_condition := true;
if (v_condition) {
var integer v_local := 0;
v_fuzzy := v_local;
v_local := 10;
}
if(v_fuzzy==10){setverdict(pass);}else{setverdict(fail);}
}
control{
execute(lazyeval());
execute(fuzzyeval());
}
}
```
## What is the current bug behavior?
lazy test case causes error (and would not pass without the division by zero). The fuzzy test case fails too.
## What is the expected correct behavior?
Both test cases shall pass
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/687initialization of @lazy and @fuzzy variables can be done by functions having ...2023-11-15T09:57:22ZLevente Erősinitialization of @lazy and @fuzzy variables can be done by functions having inout and out parameters## Summary
The condition in the title is not allowed according to Restriction e) in Section 11.1 of the TTCN-3 standard. Titan however, allows this.
## Steps and/or TTCN-3 code to reproduce
```
function noinoutps() return integer{
v...## Summary
The condition in the title is not allowed according to Restriction e) in Section 11.1 of the TTCN-3 standard. Titan however, allows this.
## Steps and/or TTCN-3 code to reproduce
```
function noinoutps() return integer{
var integer i:=2;
var integer j;
inoutps(i,j);
return 2;
}
function inoutps(inout integer i, out integer j) return integer{
j:=i;
i:=3;
return 3;
}
testcase fuzzy_lazy_ass() runs on ct_empty{
var integer i:=2;
var integer j;
var @lazy integer lv;
@try{
lv := inoutps(i,j);
}@catch(msg){
setverdict(pass);
}
var @lazy integer lv2 := noinoutps();
i:=2;
var @fuzzy integer fv;
@try{
fv := inoutps(i,j);
}@catch(msg){
setverdict(pass);
}
var @fuzzy integer fv2 := noinoutps();
}
```
## What is the current bug behavior?
The testcase has a none verdict.
## What is the expected correct behavior?
The testcase shall have a pass verdict (due to the problematic initializations -- with inoutps running into an error). That is, using ```inoutps(i,j)``` for initializing variables lv and fv shall cause an error.
## Relevant logs and/or screenshots
## Possible fixes
## Titan version
8.1.0
## Platform details (OS type and version)
Microsoft Windows 10 Enterprise 10.0.19042
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/693ASN.1 SelectionOption is not supported2023-11-15T09:57:17ZAdam KnappASN.1 SelectionOption is not supported## Summary
ASN.1 `SelectionOption` is not supported, i.e. `WITH SUCCESSORS` and `WITH DESCENDANTS`.
The IEE1609.2.1 standards are using extensively the statement WITH SUCCESSOR, therefore it would be nice to have it in Titan as well.
T...## Summary
ASN.1 `SelectionOption` is not supported, i.e. `WITH SUCCESSORS` and `WITH DESCENDANTS`.
The IEE1609.2.1 standards are using extensively the statement WITH SUCCESSOR, therefore it would be nice to have it in Titan as well.
The issue originates from this forum topic: https://www.eclipse.org/forums/index.php/t/1112635/
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/694Template initialization error2023-11-15T09:57:11ZLenard NagyTemplate initialization error## Summary
Original Titan Forum article:
https://www.eclipse.org/forums/index.php/t/1112705/
## Steps and/or TTCN-3 code to reproduce
[proba.ttcn](/uploads/2ce1c6fbbf9f5d026872aab8755fdd7e/proba.ttcn)
## What is the current bug behav...## Summary
Original Titan Forum article:
https://www.eclipse.org/forums/index.php/t/1112705/
## Steps and/or TTCN-3 code to reproduce
[proba.ttcn](/uploads/2ce1c6fbbf9f5d026872aab8755fdd7e/proba.ttcn)
## What is the current bug behavior?
Compiler crash
## Titan version
8.3.0
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/699Uncompilable generated code2023-11-15T09:57:06ZGábor SzalaiUncompilable generated code## Summary
The TITAN generates uncompilable code from the ASN.1 file
## Steps and/or TTCN-3 code to reproduce
Try to compile the generated code
## What is the current bug behavior?
error: redeclaration of ‘size_t pos’
size_t pos = p...## Summary
The TITAN generates uncompilable code from the ASN.1 file
## Steps and/or TTCN-3 code to reproduce
Try to compile the generated code
## What is the current bug behavior?
error: redeclaration of ‘size_t pos’
size_t pos = p_buf.get_pos();
^~~
error: redeclaration of ‘OER_struct tmp_oer’
OER_struct tmp_oer;
^~~~~~~
## Titan version
Latest
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/700Compilation issue in getter/setter functions2023-11-15T09:57:00ZBotond BaranyiCompilation issue in getter/setter functionsThe 'is_in_getter_scope' and 'is_in_setter_scope' functions don't compile on Alpine Linux.
See https://www.eclipse.org/forums/index.php/t/1113087/The 'is_in_getter_scope' and 'is_in_setter_scope' functions don't compile on Alpine Linux.
See https://www.eclipse.org/forums/index.php/t/1113087/Botond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/701AtNotation issue causing problems in BER and OER decoding2023-11-15T09:56:55ZAdam KnappAtNotation issue causing problems in BER and OER decodingDear Support,
I got an issue while decoding a COER packet encoded by TITAN COER codec.
I attached the sample project to illustrate the issue. The error is:
hello_world.ttcn:211: Dynamic test case error: Unbound left operand of integer c...Dear Support,
I got an issue while decoding a COER packet encoded by TITAN COER codec.
I attached the sample project to illustrate the issue. The error is:
hello_world.ttcn:211: Dynamic test case error: Unbound left operand of integer comparison.
It is linked ASN.1 files provided by IEEE 1609.2, IEEE 1609.2.1 and ETSI 103 759.
Many thanks in advanced for your support,
Best Regards,
Yann Garcia
The issue originates from this forum topic: https://www.eclipse.org/forums/index.php/t/1112887/Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/702integer is not treated as integer: The union type LENGTHTO field must contain...2023-11-15T09:56:50ZGábor Szalaiinteger is not treated as integer: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields## Summary
the
type integer INT1
is not identified as integer
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type union my_attribute_length {
INT1 short_length,
LIN2_BO_LAST extended_length
}
type record my_a...## Summary
the
type integer INT1
is not identified as integer
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type union my_attribute_length {
INT1 short_length,
LIN2_BO_LAST extended_length
}
type record my_attribute {
my_attribute_length attribute_length,
octetstring attribute_value
} with {
variant (attribute_length) "LENGTHTO(attribute_value)"
}
type integer INT1 (0..255) with { variant "FIELDLENGTH(8)" };
type integer LIN2_BO_LAST (0..65535) with { variant "FIELDLENGTH(16), COMP(nosign), BYTEORDER(last)" };
} with {
encode "RAW"
}
```
## What is the current bug behavior?
proba.ttcn:8.6-11.1: error: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields
proba.ttcn:8.6-11.1: error: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields
## What is the expected correct behavior?
no error
## Relevant logs and/or screenshots
The
```
type union my_attribute_length {
integer short_length,
integer extended_length
} with {
variant (short_length) "FIELDLENGTH(8)"
variant (extended_length) "FIELDLENGTH(16), COMP(nosign), BYTEORDER(last)"
}
```
compiled correctly
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/691PER codec2023-11-15T09:42:31ZBotond BaranyiPER codecImplement the PER codec for ASN.1 types.
/cc @aknappqwt @mmagyariImplement the PER codec for ASN.1 types.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/696Extension additions of a SEQUENCE/SET are not set to optional2023-09-06T12:59:16ZAdam KnappExtension additions of a SEQUENCE/SET are not set to optional## Summary
According to the ASN.1 standard, "All fields in extension additions of a SEQUENCE type or a SET type shall be transformed to optional fields". This behavior is missing currently.
Originates from this forum post: https://www....## Summary
According to the ASN.1 standard, "All fields in extension additions of a SEQUENCE type or a SET type shall be transformed to optional fields". This behavior is missing currently.
Originates from this forum post: https://www.eclipse.org/forums/index.php/t/1112865/
## Titan version
All
## Platform details (OS type and version)
All
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/514Document usage of OLD_LIBEDIT2023-07-25T14:57:22ZEclipse WebmasterDocument usage of OLD_LIBEDIT## Submitted by Jeno Attila Balasko
Assigned to **Jeno Attila Balasko**
**[Link to original bug (#567668)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=567668)**
## Description
OLD_LIBEDIT := yes shall be appended to Ma...## Submitted by Jeno Attila Balasko
Assigned to **Jeno Attila Balasko**
**[Link to original bug (#567668)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=567668)**
## Description
OLD_LIBEDIT := yes shall be appended to Makefile.personal if your libedit is older than 2.0.53 i.e readline.h contains info v1.34 or older.
Version: 7.1.0