titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2021-06-07T15:04:54Zhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/540Issue on templates not fully defined being Derived templates2021-06-07T15:04:54ZEclipse WebmasterIssue on templates not fully defined being Derived templates## Submitted by Carlos Arroyo
**[Link to original bug (#570801)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=570801)**
## Description
Created attachment 285425
NBIOT ATS
Dear Support,
We have noticed an error on our l...## Submitted by Carlos Arroyo
**[Link to original bug (#570801)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=570801)**
## Description
Created attachment 285425
NBIOT ATS
Dear Support,
We have noticed an error on our latest delivery, 20wk50, which could be catched by your tool if considered.
We found several places in the code where optional template fields being left uninitialized are not raising any warning.
-> A warning could be the raised on derived templates if it is not fully defined.
One example is as follows (module `.\NBIOT_IWD_20wk50 \NBIOT\22_3 NBIOT_MAC_Testcases.ttcn`)
~~~
template (value) NB_SYSTEM_CTRL_REQ cads_NB_SYSTEM_CTRL_REQ_CellConfig_NPDCCH(NBIOT_CellId_Type p_CellId,
template (value) TimingInfo_Type p_TimingInfo := cs_TimingInfo_Now,
template (omit) boolean p_CnfFlag := omit,
template (value) NPdcchConfig_Type p_NPdcchConfig)
modifies cas_NB_SYSTEM_CTRL_REQ_CellConfigOmit :=
{ /* @status APPROVED (NBIOT) */
Request := {
Cell := {
AddOrReconfigure := {
Basic := {
PhysicalLayerConfigDL := {
NPdcch := p_NPdcchConfig -> template not fully defined, this could cause problems as the other IEs may not be initialized
}
}
}
}
}
};
~~~
Being the record definition:
~~~
type record NB_PhysicalLayerConfigDL_Type { /* all fields are declared as optional to allow single reconfigurations; in this case omit means "keep as it is" */
AntennaConfig_Type Antenna optional,
NPbchConfig_Type NPbch optional,
NPdcchConfig_Type NPdcch optional,
NPdschConfig_Type NPdsch optional,
NB_PrimarySyncSignal_Type NPss optional,
NB_SecondarySyncSignal_Type NSss optional,
NB_LTE_CellSpecificReferenceSignal_Type LteCrs optional /* if omitted in initial configuration the CRS shall be considered as being not present, i.e. shall not be transmitted by the SS */
};
~~~
Same case happens with templates `cads_NB_ULGrantScheduling_REQ`, `cads_NB_CcchDcchDtchDL_Config_REQ`, `cads_NB_DrxCtrl_REQ` and `cads_NB_RachProcedure_Config_REQ` also included on the attached ATS.
With the template above some fields remained uninitialised and the issue wasn’t seen so we’d like to get it catched by tools. As you mentioned already, if some contents of a base template are never used in communication operation this design doesn't cause any problem but in this specific case I tend to think that if a derived template is not fully defined (although the pending elements are optional) it has to include all values. This is assuming a scenario working with modified templates.
Please do not hesitate to let me know whether you need more information for this issue.
Also, find attached the ATS where you can find the listed templates and type definitions.
Let me also take the opportunity to ask whether you plan to upload the installers of version 7.2.0 for Linux distros and if you will also do it for Windows versions on:
https://projects.eclipse.org/projects/tools.titan/downloads
Best Regards,
Carlos - MCC TF160
**Attachment 285425**, "NBIOT ATS":
[NBIOT_IWD_20wk50.zip](/uploads/e342aa4ac9a852d8686d6a865c7160eb/NBIOT_IWD_20wk50.zip)
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/539Updating the supported standard version in the documentation2021-06-07T15:06:29ZEclipse WebmasterUpdating the supported standard version in the documentation## Submitted by Kristof Szabados
**[Link to original bug (#570787)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=570787)**
## Description
As seen in https://www.eclipse.org/forums/index.php/t/1106722/ the documentation of...## Submitted by Kristof Szabados
**[Link to original bug (#570787)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=570787)**
## Description
As seen in https://www.eclipse.org/forums/index.php/t/1106722/ the documentation of Titan still lists 4.1.1 as the supported version of the TTCN-3 standard and also users would like TTCN-3 to support newer versions.
For this reason, it would be a good idea to update the latest supported version of the TTCN-3 standard in the documentation of Titan.
Please note, that this does request does not require any change in the codebase of Titan, only in the documentation (as such maybe it should not be done by developers, but maybe the managers of the project).
Both the current documentation of TITAN and the latest TTCN-3 (and ASN.1) standard have to be read carefully (including the extensions of the TTCN-3 standard) and the list of features supported/missing updated accordingly.
Version: 7.2.0Lenard NagyLenard Nagyhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/537check the usage of expstring_t in the runtime (core)2021-06-07T15:08:15ZEclipse Webmastercheck the usage of expstring_t in the runtime (core)## Submitted by Kristof Szabados
**[Link to original bug (#569649)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569649)**
## Description
expstring_t is a special type (actually typedef) used in the compiler, to help with...## Submitted by Kristof Szabados
**[Link to original bug (#569649)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569649)**
## Description
expstring_t is a special type (actually typedef) used in the compiler, to help with generating large amounts of code, and also provide us with debugging support.
It should not have been used in the generated code and the runtime executables.
But for some reason it has sneaked into the core folder, and is used in logging.
This should be reviewed, and if possible replaced with char* to be in line with the original plans.
Also as the necessary tools providing the benefit of this type in the compiler are not available in the runtime ... there is no purpose of this type there.
Version: 7.1.0Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/535Automatically maximalizing information about failing tests in CI systems2021-05-04T12:03:30ZEclipse WebmasterAutomatically maximalizing information about failing tests in CI systems## Submitted by Kristof Szabados
**[Link to original bug (#569215)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569215)**
## Description
Sometimes tests running in CI systems, do find problems ... that is why we have the...## Submitted by Kristof Szabados
**[Link to original bug (#569215)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569215)**
## Description
Sometimes tests running in CI systems, do find problems ... that is why we have them, sometimes they fail because of circumstantial reasons unrealated to their purpose.
However after the failure, when investigating the issue ... it does matter how much information is available to the user/developer/person doing the debugging work.
Titan is in a unique position, where it is possible to maximize the information available automatically for the user.
What could be possible:
1)
Using XCoverage to drive the CI processes, when it notices a test failing ... it could re-execute the same test 2-3 more times.
This way next morning, when checking the log, it would be immediately known, if the test was failing consistently for the same reason (and so is most probably reproducible) or inconsistently ( most probably related to some environmental factor)
2)
Having control of the configuration file, it would be possible to run the test once with all logging options enabled ... to have more information in the logs.
3)
Using the version handling system it might be possible to identify which exact commit caused the test to fail.
And as Titan already supports an automatic refactoring feature, which is able to insert extra log statements into the code (logging all visible variables)...
It would be possible to create a version of the code, where before each changed line, the values of all visible variables would be logged ... do a compilation and execution.
---
This would also mean, that by default the tests could run with few log statements in the code, reducing logging settings in the configuration file ... optimized for runtime performance.
And the CI system could automatically enhance all of these settings to extract as much information as possible about the issue ... reducing the time needed to debug it.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/534Could Titan use GPUs to speed up encoding/decoding messages?2021-06-07T15:14:05ZEclipse WebmasterCould Titan use GPUs to speed up encoding/decoding messages?## Submitted by Kristof Szabados
**[Link to original bug (#569211)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569211)**
## Description
It might be worth a try to see if Titan could use GPUs to speed up the encoding/dec...## Submitted by Kristof Szabados
**[Link to original bug (#569211)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=569211)**
## Description
It might be worth a try to see if Titan could use GPUs to speed up the encoding/decoding of messages (at least for some encodings and some protocols).
Most of the time, the actual real-life encoding/decoding needed to be done is not very complicated.
And for many messages or message parts, a GPU based implementation might be able to do the work much faster.
For example encode all elements of a record of integer at the same time, so that they just need to be chained together to finis the coding work.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/518refactoring of tests for reducing compilation time2021-05-04T12:07:51ZEclipse Webmasterrefactoring of tests for reducing compilation time## Submitted by Kristof Szabados
**[Link to original bug (#568433)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=568433)**
## Description
It was noticed as a result of the last architectural refactoring of Titan's tests (...## Submitted by Kristof Szabados
**[Link to original bug (#568433)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=568433)**
## Description
It was noticed as a result of the last architectural refactoring of Titan's tests (https://www.eclipse.org/forums/index.php/t/1101912/) that moving from a strictly sequencial build, to a build that can be parallelized improves build performance ... and in the case of tests this results in faster response execution times and faster response from the CI system.
This work should be continued:
- the encoding related tests (touched by that refactoring) should be divided into more and smaller files.
- other parts of the regression tests should also be refactored in this spirit
These changes could improve productivity, as developers will be able to learn if their change broke something much faster.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/494Debugger uplift2021-05-04T12:15:36ZEclipse WebmasterDebugger uplift## Submitted by Elemer Lelik
**[Link to original bug (#565300)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=565300)**
## Description
The Titan TTCN-3 debugger functionality has to be:
-verified against latest changes (t...## Submitted by Elemer Lelik
**[Link to original bug (#565300)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=565300)**
## Description
The Titan TTCN-3 debugger functionality has to be:
-verified against latest changes (this possibly includes writing batch mode regression test cases )
-extended to cover the new area of OOP features
Ideally this should be timed when OOP features are complete or close to completion.
Version: 7.1.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/488decvalue for RFC4826 XML fails2021-05-04T12:17:25ZEclipse Webmasterdecvalue for RFC4826 XML fails## Submitted by Elemer Lelik
**[Link to original bug (#564193)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=564193)**
## Description
Created attachment 283226
Compressed TTCN-3 project
see https://www.eclipse.org/forum...## Submitted by Elemer Lelik
**[Link to original bug (#564193)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=564193)**
## Description
Created attachment 283226
Compressed TTCN-3 project
see https://www.eclipse.org/forums/index.php/t/1104098/:
Hi Titan- XML experts,
I think there is a bug in decvalue when decoding simple RFC 4826 XML data .
/*
* Test decvalue for XML type ResourceLists_Type
*/
function f_test_decvalue_ResourceLists() {
const charstring tsc_ResourceLists_1 := "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" &
"<resource-lists xmlns=\"urn:ietf:params:xml:ns:resource-lists\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n" &
" `<list>`\n" &
" <entry uri=\"org.3gpp.mcptt.ue-config/users/urn:uuid:e740ed78-ca4f-4435-8006-a4d97925a684\"/>\n" &
" `</list>`\n" &
"`</resource-lists>`\n";
var ResourceLists_Type v_DecodedResourceLists;
var bitstring v_BitStr;
v_BitStr := oct2bit(char2oct( tsc_ResourceLists_1));
if (decvalue(v_BitStr, v_DecodedResourceLists) != 0) {
log(v_DecodedResourceLists);
setverdict(fail);
} else {
setverdict(pass);
}
}
The good news is that only the return value is incorrect, the decoded value is correct :-)
Attached my sub-project.
Regards,
Olaf
**Attachment 283226**, "Compressed TTCN-3 project":
[DemoTitanBug.zip](/uploads/c49d3a4b5d184207fce781737ebf4efc/DemoTitanBug.zip)
Version: 6.6.1https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/485add support for assigning values to sets with value list notation2021-05-04T12:18:43ZEclipse Webmasteradd support for assigning values to sets with value list notation## Submitted by Kristof Szabados
**[Link to original bug (#563226)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=563226)**
## Description
In the current version of the TTCN-3 standard it is possible to assign a value to a...## Submitted by Kristof Szabados
**[Link to original bug (#563226)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=563226)**
## Description
In the current version of the TTCN-3 standard it is possible to assign a value to a set typed definition using value list notation.
This method is not yet supported by Titan.
According to the standard it should work like this:
"When the value list notation is used for values of set types, the values are assigned to the fields in the sequential order of the fields in the type definition. " from section 6.2.2.0 of v4.12.1 of the core standard
Version: 6.6.1https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/484RAW codec: Odd behavior of PADDING attribute2021-06-07T15:30:11ZEclipse WebmasterRAW codec: Odd behavior of PADDING attribute## Submitted by Vadim Yanitskiy
**[Link to original bug (#562849)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562849)**
## Description
Created attachment 282713
Test module demonstrating the problem
For a long time I'v...## Submitted by Vadim Yanitskiy
**[Link to original bug (#562849)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562849)**
## Description
Created attachment 282713
Test module demonstrating the problem
For a long time I've been facing odd and unpredictable behavior of the 'PADDING' attribute, so finally I found some time and came up with a test module demonstrating it. Please see the attachment.
In that module I basically define three different messages:
* MessageType1 - always occupies 6 octets (no padding),
* MessageType2 - shall be aligned to 8 octets ('2B'O padding),
* MessageType3 - shall be aligned to 13 octets ('2B'O padding),
which are then grouped into a union 'MessagePayload' and prefixed with a simple header. Unlike the first message, both second and third contain a flexible octetstring called 'rest_octets' at the end with variable length. So the actual contents of the 'rest_octets' may be shorter or even omitted (i.e. an empty octetstring).
Regardless of the actual length of the 'rest_octets', both second and third messages shall be aligned to 8 and 13 octets respectively. This is what I am trying to achieve using the PADDING attributes. Note that I cannot apply padding to the final record combining the message header and the payload, because of the length constraints mentioned above.
For the sake of diversity, in case of the second message I applied padding to the whole record. For the third message, the padding is applied directly to the 'rest_octets'. Unfortunately, neither of this variants works as expected. Because of that, on practice [1][2][3] I have to work this around by adding / stripping padding bytes manually.
Interestingly enough, this (mis)behavior is not observed when padding is applied to a top-level record that is passed to the RAW codec, i.e. the 'Message' in this example. But as I stated, this is not what I need.
[1] https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18026
[2] https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15571
[3] https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15488
**Attachment 282713**, "Test module demonstrating the problem":
[TITAN_PaddingTest.ttcn](/uploads/97f51d0abd1be81ccd923142435c92b3/TITAN_PaddingTest.ttcn)
Version: 6.6.1https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/482Incorrect order in TTCN-3 record generated by xsd2ttcn2021-05-04T12:20:38ZEclipse WebmasterIncorrect order in TTCN-3 record generated by xsd2ttcn## Submitted by Elemer Lelik
**[Link to original bug (#562102)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562102)**
## Description
Created attachment 282436
Schema files
The TTCN-3 file generated based on the attached...## Submitted by Elemer Lelik
**[Link to original bug (#562102)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562102)**
## Description
Created attachment 282436
Schema files
The TTCN-3 file generated based on the attached schemas (urn_ietf_params_xml_ns_xcap_diff.ttcn) contain an incorrect order for
the record DocumentType:
type record DocumentType
{
XSD.String new_etag optional,
XSD.String previous_etag optional,
XSD.AnyURI sel,
record of XSD.String attr optional,
union {
EmptyType body_not_changed,
record of record {
union {
record {
Pos pos optional,
Xpath_add sel,
Type type_ optional,
record of XSD.String attr optional,
record of XSD.String embed_values_1,
record of XSD.String elem_list
} add,
record {
Xpath sel,
Ws ws optional,
record of XSD.String attr optional
} remove,
record {
Xpath sel,
record of XSD.String attr optional,
record of XSD.String embed_values_1,
XSD.String elem optional
} replace_,
XSD.String elem
} choice
} sequence_list
} choice optional
}
:
as revealed by the compilation error:
make
/home/james00/titan.core/Install/bin/compiler -L \
urn_ietf_params_xml_ns_xcap_diff.ttcn UsefulTtcn3Types.ttcn XSD.ttcn - urn_ietf_params_xml_ns_xcap_diff.ttcn UsefulTtcn3Types.ttcn XSD.ttcn
Notify: Parsing TTCN-3 module `urn_ietf_params_xml_ns_xcap_diff.ttcn'...
Notify: Parsing TTCN-3 module `UsefulTtcn3Types.ttcn'...
Notify: Parsing TTCN-3 module `XSD.ttcn'...
Notify: Checking modules...
urn_ietf_params_xml_ns_xcap_diff.ttcn: In TTCN-3 module `urn_ietf_params_xml_ns_xcap_diff':
urn_ietf_params_xml_ns_xcap_diff.ttcn:140.1-154.1: In type definition `Xcap_diff':
urn_ietf_params_xml_ns_xcap_diff.ttcn:144.2-153.20: In record field `sequence':
urn_ietf_params_xml_ns_xcap_diff.ttcn:145.3-151.17: In record field `sequence_list':
urn_ietf_params_xml_ns_xcap_diff.ttcn:145.3-151.3: In embedded type of record of:
urn_ietf_params_xml_ns_xcap_diff.ttcn:146.4-150.11: In record field `choice':
urn_ietf_params_xml_ns_xcap_diff.ttcn:147.5-25: In union field `document':
urn_ietf_params_xml_ns_xcap_diff.ttcn:173.1-206.1: In type definition `DocumentType':
urn_ietf_params_xml_ns_xcap_diff.ttcn:183.5-190.5: error: A type with EMBED-VALUES must be a sequence type. The first component of the sequence shall be SEQUENCE OF UTF8String and shall not be marked DEFAULT
urn_ietf_params_xml_ns_xcap_diff.ttcn:196.5-201.5: error: A type with EMBED-VALUES must be a sequence type. The first component of the sequence shall be SEQUENCE OF UTF8String and shall not be marked DEFAULT
the correct order being:
type record DocumentType
{
XSD.String new_etag optional,
XSD.String previous_etag optional,
XSD.AnyURI sel,
record of XSD.String attr optional,
union {
EmptyType body_not_changed,
record of record {
union {
record {
record of XSD.String embed_values_1,//has to be first!!!!
Pos pos optional,
Xpath_add sel,
Type type_ optional,
record of XSD.String attr optional,
record of XSD.String elem_list
} add,
record {
Xpath sel,
Ws ws optional,
record of XSD.String attr optional
} remove,
record {
record of XSD.String embed_values_1, //has to be first!!!
Xpath sel,
record of XSD.String attr optional,
XSD.String elem optional
} replace_,
XSD.String elem
} choice
} sequence_list
} choice optional
}
:
**Attachment 282436**, "Schema files":
[XSD.zip](/uploads/93769a165368070713e719f118f820f5/XSD.zip)
Version: 6.6.1https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/480Clean-up after reference refactoring2021-05-04T12:22:11ZEclipse WebmasterClean-up after reference refactoring## Submitted by Botond Baranyi
**[Link to original bug (#561729)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=561729)**
## Description
A few minor tasks were left out of the reference refactoring:
- merging the Ref_base...## Submitted by Botond Baranyi
**[Link to original bug (#561729)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=561729)**
## Description
A few minor tasks were left out of the reference refactoring:
- merging the Ref_base class with the Ttcn::Reference class, as it no longer serves any purpose (it was the abstract base class for the Ttcn::Reference and Ref_pard classes),
- renaming the FieldAndArrayRef class, since it can now also contain function references, not just field names and array indexes,
- some of the functions in Ttcn::Reference could probably be optimized (in most cases only an 'if' was added to separate the 'Ref_pard' code from the original 'Ttcn::Reference' code).
Version: 6.6.1https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/479Rework 'rearrange_init_code' functions2021-05-05T13:03:51ZEclipse WebmasterRework 'rearrange_init_code' functions## Submitted by Botond Baranyi
**[Link to original bug (#561714)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=561714)**
## Description
The 'rearrange_init_code' functions in the TTCN-3 compiler ensure that values and tem...## Submitted by Botond Baranyi
**[Link to original bug (#561714)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=561714)**
## Description
The 'rearrange_init_code' functions in the TTCN-3 compiler ensure that values and templates are initialized in the correct order in C++, even if in TTCN-3 they are used before their initialization.
During the recent reference refactoring some irregularities have been discovered in these functions.
Version: 6.6.1https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/469[CR] new features in the Object Oriented extension2021-05-05T13:07:51ZEclipse Webmaster[CR] new features in the Object Oriented extension## Submitted by Kristof Szabados
**[Link to original bug (#558724)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558724)**
## Description
The latest version of the TTCN-3 standard's Object Oriented featues extension will ...## Submitted by Kristof Szabados
**[Link to original bug (#558724)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558724)**
## Description
The latest version of the TTCN-3 standard's Object Oriented featues extension will include some new features.
- Libraries of useful data types/data structures: http://oldforge.etsi.org/mantis/view.php?id=7863
- allowing nested classes: http://oldforge.etsi.org/mantis/view.php?id=7866
- type parameterization: http://oldforge.etsi.org/mantis/view.php?id=7853
(although technically written into the advanced parameterisation extension)
Version: 6.6.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/468[CR] allowing "any" type as a formal parameter to external functions2021-05-05T13:08:35ZEclipse Webmaster[CR] allowing "any" type as a formal parameter to external functions## Submitted by Kristof Szabados
**[Link to original bug (#558722)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558722)**
## Description
The latest version of the TTCN-3 standard enables the user to use any type as the t...## Submitted by Kristof Szabados
**[Link to original bug (#558722)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558722)**
## Description
The latest version of the TTCN-3 standard enables the user to use any type as the type of a formal parameter of an external function.
CR 7455: http://oldforge.etsi.org/mantis/view.php?id=7455
Although the notation is used for predefined function it is not expected to bring changes for them, as per the declared semantics.
The benefit of this approach is that user will be able to pass any type as a parameter for an external function (for example printf can be implemented now).
But this also means that on the implementation side of the external function, the native code will have offer specialised implementation for all types that can be reasonably expected to be passed as parameters.
(for example most probably integers have to be handled differently from records)
It is important to note, that later down the line this might create maintenance problems for the users.
For example if base libraries start to use this function, they might need to be updated every time some code calling their functions, uses a new type that needs some special behiour to handle.
Version: 6.6.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/467[CR] TTCN-3 standard extended with a map type2021-05-05T13:09:01ZEclipse Webmaster[CR] TTCN-3 standard extended with a map type## Submitted by Kristof Szabados
**[Link to original bug (#558721)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558721)**
## Description
The new TTCN-3 standard (v 4.12.1) is extended with a new type, that offer support ...## Submitted by Kristof Szabados
**[Link to original bug (#558721)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558721)**
## Description
The new TTCN-3 standard (v 4.12.1) is extended with a new type, that offer support for key-value mapped data storage and retrieval.
(coming from CR 7682: http://oldforge.etsi.org/mantis/view.php?id=7682)
Please note, that although the Object-Oriented extension might offer better support for such data structures as per efficiency and user customization, this version is embedded natively into the language, offering for example index operators.
Version: 6.6.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/466[CR] [BIC] upcoming TTCN-3 standard will include a change in how partially in...2021-05-05T13:09:42ZEclipse Webmaster[CR] [BIC] upcoming TTCN-3 standard will include a change in how partially initialized templates are handled## Submitted by Kristof Szabados
**[Link to original bug (#558720)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558720)**
## Description
In the updoming TTCN-3 standard (v. 4.12.1), there will be a change in the handling...## Submitted by Kristof Szabados
**[Link to original bug (#558720)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558720)**
## Description
In the updoming TTCN-3 standard (v. 4.12.1), there will be a change in the handling of partially initialized tmeplates as per CR 7883 (http://oldforge.etsi.org/mantis/view.php?id=7883)
Now the users will have to mark partially initialized templates with the "@abstract" notation.
Letting the tools offer stronger semantic analysis opportunities for their users.
Please note, that the current behaviour (where partially initialized templates do not have to be marked specially) is becoming deprecated.
It can still be supported for some time.
BUT will become non-standard compliant at some time in the future.
Please also note, that we should also develop a refactoring feature once support for this feature is implemented in the semantic checkers. This will make updating the millions of lines of code our users have much easier for them.
Version: 6.6.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/465[CR] supporting reference types in structured types2021-05-05T13:10:20ZEclipse Webmaster[CR] supporting reference types in structured types## Submitted by Kristof Szabados
**[Link to original bug (#558719)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558719)**
## Description
There was a change in the standard that allows the user to create records with for ...## Submitted by Kristof Szabados
**[Link to original bug (#558719)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=558719)**
## Description
There was a change in the standard that allows the user to create records with for example port type fields.(restriction was removed)
The benefit of this behaviour is the better structuring of information, where ports, components, timers would be used in structured information, possibly with some additional data.
But please note, that several operations with such types/data structures are not permitted, for example: sending them over them network.
Which has to be detected differently.
Please note the phrasing in the standard (V4.11.1):
22.2.1: "The send operation places a message on an outgoing message port. The message may be specified by referencing a defined template or can be defined as an in-line template."
15.0 restriction b): "Templates shall not be of a structured type that contains fields of default, port or timer type on any level of nesting."
As such effectively records with port type field can not be sent over the network.
This is described by saying that only templates can be send on the network + saying that templates can not be created from such structured types.
Please note:
- the whole standard needs to be reviewed carefully before implementing the change.
- this will also change error messages reported by the compiler.
Version: 6.6.0https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/419ASN.1 presence constraint is ignored by the compiler2021-05-05T12:38:32ZEclipse WebmasterASN.1 presence constraint is ignored by the compiler## Submitted by Botond Baranyi
**[Link to original bug (#540177)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=540177)**
## Description
Created attachment 276260
Example TTCN-3 file with constants and OER encoding
The co...## Submitted by Botond Baranyi
**[Link to original bug (#540177)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=540177)**
## Description
Created attachment 276260
Example TTCN-3 file with constants and OER encoding
The compiler ignores presence constraints for ASN.1 types when checking values.
See the constants defined in the attached example.
**Attachment 276260**, "Example TTCN-3 file with constants and OER encoding":
[test.ttcn](/uploads/a5d471ae849e8dd5c66eeebc6eb3beb0/test.ttcn)
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.0