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 |
|
|
|
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) |
|
|
|
|
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. |
|
|
|
|
|
STF discussion: add a definition for invalid expressions/operations in the definitions part describing that invalid things will lead to errors being raised |
|
|
|
|
|
|
|
|
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. |
|
|
|
|
"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. |
|
|
|
|
|
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. |
|
|
|
|
|
Implemented in draft 4.12.2 |
|