Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007964Part 01: TTCN-3 Core LanguageNew Featurepublic29-06-2020 20:0216-12-2020 15:02
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Summary0007964: Assigning a universal charstring value to a charstring variable is now allowed, but very error prone
DescriptionThe 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.
TagsNo tags attached.
Clause Reference(s)6.3.1
Source (company - Author)     L.M. Ericsson
Attached Filesdocx file icon CR_7964.docx [^] (201,496 bytes) 11-08-2020 16:55
docx file icon CR_7964-2.docx [^] (201,261 bytes) 12-08-2020 14:30

- Relationships

-  Notes
(0015665)
Wolfgang Seka (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
11-08-2020 16:55

 Please review.
(0015712)
Jacob Wieland - Spirent (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
16-12-2020 15:02

 Implemented in draft 4.12.2

- 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)

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker