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

(0011884)
Jacob Wieland - Spirent
12-12-2013 13:01

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.

(0011941)
Gyorgy Rethy
07-04-2014 14:27

stf478, 2014-04-07: Add a formal rule to decide the type implicitly according to content. Add the same rules to substring and replace.

(0012004)
Axel Rennoch
10-04-2014 13:28

Problem: parameters of regexp may have no type information Approach: types of literal arguments should be derived from the contents

(0012273)
Jens Grabowski
08-10-2014 10:39

Wording slightly changed.

(0012655)
Gyorgy Rethy
06-01-2015 18:49

Added to draft V4.6.3