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

ID | Project | Category | View Status | Date Submitted | Last Update
0007964 | Part 01: TTCN-3 Core Language | New Feature | public | 29-06-2020 20:02 | 16-12-2020 15:02

Reporter | KristÃ³f Szabados |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | 4.12.1 (published 2020-05) |
Target Version | 4.13.1 (ongoing) | Fixed in Version | 4.13.1 (ongoing) |
Clause Reference(s) | 6.3.1
Source (company - Author) | L.M. Ericsson

Summary | 0007964: Assigning a universal charstring value to a charstring variable is now allowed, but very error prone

Description

The current type compatibility rules of the TTCN-3 standard allows to assign a universal charstring value to a charstring variable.
See section 6.3.1
There is an actual example in example 4.
This is very error prone:
- if the universal charstring has even a single character that does not fit into the charstring, a runtime error has to be produced.
- Most of the time universal charstrings are used when the expected values, do not fit into the charstring restrictions.
- In most practical situations, this is impossible to check in compilation time ... leading to unexpected runtime errors.
If this kind of assignment is needed maybe we could have a predefined function, that converts only the universal characters that are actually characters and never fails.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR_7964.docx (201,496) 11-08-2020 16:55 http://oldforge.etsi.org/mantis/file_download.php?file_id=3915&type=bug CR_7964-2.docx (201,261) 12-08-2020 14:30 http://oldforge.etsi.org/mantis/file_download.php?file_id=3926&type=bug

Issue History
Date Modified | Username | Field | Change
29-06-2020 20:02 | KristÃ³f Szabados | New Issue |
01-07-2020 10:14 | Wolfgang Seka | Note Added: 0015665 |
10-08-2020 10:22 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-08-2020 10:23 | Jens Grabowski | Assigned To | => Jacob Wieland - Spirent
10-08-2020 10:23 | Jens Grabowski | Status | new => assigned
11-08-2020 12:14 | Jacob Wieland - Spirent | Note Added: 0015689 |
11-08-2020 13:19 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
11-08-2020 13:20 | Jacob Wieland - Spirent | Note Added: 0015695 |
11-08-2020 16:55 | KristÃ³f Szabados | File Added: CR_7964.docx |
11-08-2020 16:55 | KristÃ³f Szabados | Note Added: 0015703 |
11-08-2020 16:55 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jacob Wieland - Spirent
12-08-2020 13:03 | Jacob Wieland - Spirent | Status | assigned => confirmed
12-08-2020 14:30 | Jacob Wieland - Spirent | File Added: CR_7964-2.docx |
12-08-2020 14:33 | Jacob Wieland - Spirent | Note Added: 0015712 |
12-08-2020 14:33 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
12-08-2020 14:33 | Jacob Wieland - Spirent | Status | confirmed => assigned
12-08-2020 14:33 | Jacob Wieland - Spirent | Status | assigned => confirmed
12-08-2020 17:21 | KristÃ³f Szabados | Note Added: 0015716 |
13-08-2020 11:47 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jacob Wieland - Spirent
13-08-2020 11:47 | KristÃ³f Szabados | Status | confirmed => assigned
13-08-2020 11:47 | KristÃ³f Szabados | Status | assigned => confirmed
13-08-2020 13:02 | Jacob Wieland - Spirent | Note Added: 0015729 |
13-08-2020 13:08 | Jacob Wieland - Spirent | Status | confirmed => resolved
13-08-2020 13:08 | Jacob Wieland - Spirent | Resolution | open => fixed
13-08-2020 13:08 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
16-12-2020 15:02 | Gyorgy Rethy | Note Added: 0015864 |
16-12-2020 15:02 | Gyorgy Rethy | Status | resolved => closed
16-12-2020 15:02 | Gyorgy Rethy | Product Version | => 4.12.1 (published 2020-05)
16-12-2020 15:02 | Gyorgy Rethy | Fixed in Version | => 4.13.1 (ongoing)
16-12-2020 15:02 | Gyorgy Rethy | Target Version | => 4.13.1 (ongoing)

Notes

(0015665)
Wolfgang Seka
01-07-2020 10:14

According to my understanding charstring and universal charstring are compatible types (ES 201 873-1 clause 6.3.1).
=> assignments shall be possible in both directions and shall not cause a compilation error.
Whether tools generate a run-time error seems to be tool dependent.
(Nevertheless on my opinion it shall be the codec raising the error - if needed)
Any further restrictions in the TTCN language would be non-compatible.
Please note in this context that the only reason why we (MCC160) need to care about universal charstring is due to definitions in XSD.ttcn.
Furthermore on my opinion there is no benefit or need for any conversion function:
A conversion function may
- raise a run time error when the universal charstring contains non-charstring characters => no benefit
- skip non-charstring characters => unpredictable side-effects
But instead there could be a build-in function to check whether a string complies to a particular character set (even though by the time being there is no need for such function from our side).
Nevertheless ES 201 873-1 may be improved to clarify that charstring is sub-type of universal charstring and shall be treated like this.
(a more progressive approach would be to go for a single character string type)

(0015689)
Jacob Wieland - Spirent
11-08-2020 12:14

As I can see it, the standard is perfectly clear when a universal charstring is compatible with charstring:
For variables, constants, templates, etc. of charstring type, value 'b' is compatible with a universal charstring type 'A' unless it violates any type constraint specification (range, list or length) of type "A".
For variables, constants, templates, etc. of universal charstring type, value 'b' is compatible with a charstring type 'A' if all characters used in value 'b' have their corresponding characters (i.e. the same control or graphical character using the same character code) in the type charstring and it does not violate any type constraint specification (range, list or length) of type "A".
When not compatible, the assignment will raise an error the same as for all other types when they are not compatible.
In my opinion, nothing needs to be done. It is a tool issue to warn the user of possible runtime problems. In that case, they are not unexpected either.

(0015695)
Jacob Wieland - Spirent
11-08-2020 13:20

STF discussion: add a definition for invalid expressions/operations in the definitions part describing that invalid things will lead to errors being raised

(0015703)
KristÃ³f Szabados
11-08-2020 16:55

Please review.

(0015712)
Jacob Wieland - Spirent
12-08-2020 14:33

I changed the wording of the proposal to not reference compilation but use static analysis instead (a tool could just do static analysis and not produce any executable at all). I also removed the 'if possible' part. Many things are possible to do but impracticle in practice (halting problem etc.), so compilers will not always do what is possible but only a subset. The standard should not force them to do all that is theoretically possible. Also, the invalid expressions will only cause runtime errors when they are actually evaluated, so I also included that part.
Please review.

(0015716)
KristÃ³f Szabados
12-08-2020 17:21

"Possibly invalid expressions should be warned about during static analysis.." That would all of the cases when a universal charstring variable or formal parameter is assigned to a charstring variable. If a tool can not evaluate constants ... also for constant of the universal charstring type.

(0015729)
Jacob Wieland - Spirent
13-08-2020 13:02

Yes, that is correct, all universal charstrings who the static analysis does not determine to contain only charstring characters should be warned about so that the runtime error is not unexpected anymore.

(0015864)
Gyorgy Rethy
16-12-2020 15:02

Implemented in draft 4.12.2