ETSI's Bug Tracker - Part 01: TTCN-3 Core Language |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0006663 | Part 01: TTCN-3 Core Language | Clarification | public | 12-12-2013 12:08 | 06-01-2015 18:49 |
|
| Reporter | Gyorgy Rethy | |
| Assigned To | Gyorgy Rethy | |
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | v4.6.1 (published 2014-06) | |
| Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) | |
| Clause Reference(s) | C.4.1 |
| Source (company - Author) | L.M.Ericsson |
|
| Summary | 0006663: regexp's behaviour if both string parameters are literals |
| Description | The current behavior of regexp is unspecified in the case when both inpar and expression are literals. e.g.:
var charstring v_temp := regexp ( "CSP-1234", "CSP-(\d#(1,4))", 0 );
Possible behaviors:
- return an error as the type of the parameters are not defined
- implicitly assume the types of the parameters from their contents (i.e. cause error in case of inpar deducted to be a charstring and expression to be a universal charstring, and return a string otherwise)
- consider the type of the variable at the LHS in a strict way, i.e. the types of the parameters shall be the same, and cause error or return a string based on this information; if there is no appropriate type to consider(e.g. inside an expression), cause an error.
|
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  CR6663_update_proposal.docx (25,317) 10-04-2014 13:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2998&type=bug
CR6663_update_proposal-V2.docx (20,655) 08-10-2014 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3107&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 12-12-2013 12:08 | Gyorgy Rethy | New Issue | |
| 12-12-2013 12:08 | Gyorgy Rethy | Clause Reference(s) | => C.4.1 |
| 12-12-2013 12:08 | Gyorgy Rethy | Source (company - Author) | => L.M.Ericsson |
| 12-12-2013 12:09 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language |
| 12-12-2013 13:01 | Jacob Wieland - Spirent | Note Added: 0011884 | |
| 07-04-2014 14:27 | Gyorgy Rethy | Note Added: 0011941 | |
| 07-04-2014 14:27 | Gyorgy Rethy | Assigned To | => Axel Rennoch |
| 07-04-2014 14:27 | Gyorgy Rethy | Status | new => assigned |
| 08-04-2014 16:52 | Gyorgy Rethy | Product Version | => v4.6.1 (published 2014-06) |
| 08-04-2014 16:52 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06) |
| 10-04-2014 13:27 | Axel Rennoch | File Added: CR6663_update_proposal.docx | |
| 10-04-2014 13:28 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy |
| 10-04-2014 13:28 | Axel Rennoch | Note Added: 0012004 | |
| 10-04-2014 13:28 | Axel Rennoch | Status | assigned => confirmed |
| 06-10-2014 15:07 | Gyorgy Rethy | Priority | normal => high |
| 08-10-2014 07:56 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski |
| 08-10-2014 10:39 | Jens Grabowski | Note Added: 0012273 | |
| 08-10-2014 10:39 | Jens Grabowski | File Added: CR6663_update_proposal-V2.docx | |
| 08-10-2014 10:39 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy |
| 08-10-2014 10:39 | Jens Grabowski | Status | confirmed => assigned |
| 08-10-2014 10:40 | Jens Grabowski | Status | assigned => resolved |
| 08-10-2014 10:40 | Jens Grabowski | Resolution | open => fixed |
| 06-01-2015 18:49 | Gyorgy Rethy | Note Added: 0012655 | |
| 06-01-2015 18:49 | Gyorgy Rethy | Status | resolved => closed |
| 06-01-2015 18:49 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06) |
|
Notes |
|
|
|
I think the restriction should simply be dropped as it serves no purpose. The return type (as the return value can only be a substring of the input parameter) follows obviously from the type of the input parameter whose type can always be inferred from the content, if it is a string literal.
It can have no detrimental effect if I use a universal charstring pattern on a charstring value (at worst, it does not match) or if I use a charstring pattern on a universal charstring value (as every charstring is implicitly also a universal charstring).
Therefore, the restriction has no purpose and can be dropped. This will also not create backward compatibility issues as it just allows more usages of regexp without changing the semantics of the previously allowed usages. |
|
|
|
|
stf478, 2014-04-07: Add a formal rule to decide the type implicitly according to content.
Add the same rules to substring and replace. |
|
|
|
|
Problem: parameters of regexp may have no type information
Approach: types of literal arguments should be derived from the contents |
|
|
|
|
|
Wording slightly changed. |
|
|
|
|
|