ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006448 | Part 01: TTCN-3 Core Language | Technical | public | 21-03-2013 10:31 | 27-08-2014 13:17

Reporter | Tomas Urban |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.6.1 (published 2014-06) | Fixed in Version | v4.6.1 (published 2014-06) |
Clause Reference(s) | 16.1.3
Source (company - Author) | Elvior

Summary | 0006448: Rules for external function parameters

Description

There's a mismatch between external function syntactical structure and restrictions. The syntactical part allows to use port and timer parameters, but the restriction a) says that no port or timer operations are allowed inside external functions.
Proposal:
External functions should have the same restrictions as signatures, i.e. only value parameters shall be allowed (with component and default type forbidden). Port, template and timer parameters shall be completely forbidden. That's because the parameters are typically passed over TRI in an encoded form and ports, timers, components, default values and matching symbols cannot be encoded.
If the above mentioned proposal is not acceptable, something has to be done with the TRI, because its current form is not capable of passing ports, timers, components, default values and matching symbols to the PA.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006793 | closed | Tomas Urban | Part 06: TTCN-3 Control Interface | Value Interface is underspecified/inconsistent for Templates

Attached Files | CR6448_resolution_v1.doc (178,176) 12-07-2013 11:50 http://oldforge.etsi.org/mantis/file_download.php?file_id=2846&type=bug CR6448_resolution_v2.doc (179,200) 12-07-2013 12:00 http://oldforge.etsi.org/mantis/file_download.php?file_id=2847&type=bug

Issue History
Date Modified | Username | Field | Change
21-03-2013 10:31 | Tomas Urban | New Issue |
21-03-2013 10:31 | Tomas Urban | Clause Reference(s) | => 16.1.3
21-03-2013 10:31 | Tomas Urban | Source (company - Author) | => Elvior
08-07-2013 15:16 | Jens Grabowski | Status | new => assigned
08-07-2013 15:16 | Jens Grabowski | Assigned To | => Gyorgy Rethy
08-07-2013 18:05 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2014-06)
09-07-2013 09:43 | Gyorgy Rethy | Note Added: 0011455 |
09-07-2013 13:34 | Jacob Wieland - Spirent | Note Added: 0011466 |
09-07-2013 13:37 | Jacob Wieland - Spirent | Note Added: 0011467 |
10-07-2013 09:01 | Gyorgy Rethy | Note Added: 0011492 |
10-07-2013 09:23 | Jacob Wieland - Spirent | Note Added: 0011494 |
10-07-2013 12:04 | Gyorgy Rethy | Note Edited: 0011455 |
10-07-2013 12:12 | Gyorgy Rethy | Note Added: 0011498 |
10-07-2013 12:24 | Gyorgy Rethy | Note Added: 0011499 |
10-07-2013 14:09 | Jacob Wieland - Spirent | Note Added: 0011503 |
10-07-2013 14:10 | Jacob Wieland - Spirent | Note Added: 0011504 |
12-07-2013 10:34 | Gyorgy Rethy | Note Added: 0011569 |
12-07-2013 11:50 | Gyorgy Rethy | File Added: CR6448_resolution_v1.doc |
12-07-2013 11:51 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
12-07-2013 11:51 | Gyorgy Rethy | Status | assigned => confirmed
12-07-2013 12:00 | Jacob Wieland - Spirent | File Added: CR6448_resolution_v2.doc |
12-07-2013 12:00 | Jacob Wieland - Spirent | Status | confirmed => assigned
12-07-2013 12:01 | Jacob Wieland - Spirent | Note Added: 0011575 |
12-07-2013 12:01 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
12-07-2013 12:01 | Jacob Wieland - Spirent | Status | assigned => confirmed
12-07-2013 12:24 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
12-07-2013 12:24 | Gyorgy Rethy | Status | confirmed => resolved
12-07-2013 12:24 | Gyorgy Rethy | Resolution | open => fixed
12-07-2013 14:19 | Ina Schieferdecker | Status | resolved => closed
12-07-2013 14:19 | Ina Schieferdecker | Fixed in Version | => v4.6.1 (published 2014-06)
27-08-2014 13:17 | Jacob Wieland - Spirent | Relationship added | related to 0006793

Notes

(0011455)
Gyorgy Rethy
09-07-2013 09:43 (edited on: 10-07-2013 12:04)

My proposal:
1) Disallow port, timer, component and default (template pars is discussed in item 2 below).
change the BNF:
233.ExtFunctionDef ::= ExtKeyword FunctionKeyword Identifier "(" [ExtFunctionFormalParList] ")" [ReturnType] /* Gyorgy: Ext... is added to FunctionFormalParList */
234.ExtKeyword ::= "external"
/* Gyorgy: new terminals */
235.ExtFunctionFormalParList ::= ExtFunctionFormalPar {"," ExtFunctionFormalPar}
236.ExtFunctionFormalPar ::= FormalValuePar | FormalTemplatePar
Change clause 16.1.3 External functions, restriction a) to:
a) External functions shall have value and template formal parameters only and are not allowed to contain component, port, timer or default handling operations.
2) Passing template parameters to external functions is used in code today, forbidding this would be backward incompatible. In some cases at functional testing both sending and receiving templates are created dynamically, sometimes using external functions, e.g. to handle data stored in databases, test management systems etc. These external functions may return ? or * in inout parameters, for example because this is explicitly specified by the user (pls. note, it not possible to check in TTCN-3 today, if a field or template contains matching, it has to be decided within the external function) or e.g. the field does not have a corresponding data in the database. It has to be discussed how to encode matching mechanisms, instead of restricting the usability of the language.

(0011466)
Jacob Wieland - Spirent
09-07-2013 13:34

the problem is more how to determine the presence and kinds of matching mechanisms in the template to be encoded (if necessary).
In my experience, though, external functions are implemented with a pseudo-encoding for the parameters anyway (just encoding some reference to the actual value/template) which later on led to the XTRI approach where no encoding is necessary.
Still, it could be useful to make information about the mechanisms at runtime accessible. Internally it needs to be accessible for logging purposes anyway so this information just needs to be exposed via a standardized API.

(0011467)
Jacob Wieland - Spirent
09-07-2013 13:37

Also, I see no reason why to restrict the parameters on ports, timers and components (or even default). For these, there are actual entities present in TRI(TriComponentId, TriPortId, TriTimerId), just not in the current value-universe (which would have to be enlarged for those).

(0011492)
Gyorgy Rethy
10-07-2013 09:01

The reason of forbidding port, timer, component and default parameters is not technical. These active TTCN-3 objects determine the component behaviour e.g. the snapshots, and we do not want that the user changes the state of these objects outside of the TTCN-3 code. These objects shall be under the control of the TE to secure tool robustness and stability.

(0011494)
Jacob Wieland - Spirent
10-07-2013 09:23

since there will always be ways around this access restriction (by giving pseudo-references to these objects to the TRI instead of the actual values and then letting the tool de-reference these references again) I don't think that such a restriction helps very much, it just makes code more complicated in case that you do need access to this kind of thing (and know what you are doing).
What should be standardized should be the same restriction as in the language itself that the Test Adaptation needs to adhere to, i.e. no state-changing operations during a snapshot. Why read-access should be restricted is beyond me.

(0011498)
Gyorgy Rethy
10-07-2013 12:12

If the user or a tool vendor wants to make its test system hard to control (potentially unstable) and hard to debug, by hacking it, this is his or her problem. The decision was many years ago that the language shall not support doing this.
The decision was that TTCN-3 active objects shall remain under the full control of the TTCN-3 tool. The CR does not require and not reasoning to change this decision, just requests making the BNF consistent with the above decision.

(0011499)
Gyorgy Rethy
10-07-2013 12:24

STF decision 2013-07-10: Proposed solution is OK, change the BNF as proposed by Gyorgy, allow template parameters and add TRI encoding for matching mechanisms: approach should be similar to TLI: distinc the very basic matching mechanism like ? and *, and the rest should be strings.

(0011503)
Jacob Wieland - Spirent
10-07-2013 14:09

before adding this new restriction which would introduce possible backward incompatibility for existing test suites, we should ask the tool vendors if they know if this feature (of ports or timers as parameters) is used anywhere.

(0011504)
Jacob Wieland - Spirent
10-07-2013 14:10

Also, we should clarify what timer and port handling operations are (I guess it should be all operation ts that change the state of a port or timer) that are disallowed to be used by external functions.

(0011569)
Gyorgy Rethy
12-07-2013 10:34

OK, Jacob is correct, it could be better to keep backward compatibility and instead of a new restriction allow operations that do not make harm to the test system. See my first draft text proposal in CR6448_resolution_v1.doc.

(0011575)
Jacob Wieland - Spirent
12-07-2013 12:01

apart from some generalization (because now we allow also templates in component types) in 16.1. restriction i), it's fine with me