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

ID | Project | Category | View Status | Date Submitted | Last Update
0006722 | Part 01: TTCN-3 Core Language | Technical | public | 10-04-2014 11:52 | 05-01-2015 16:13

Reporter | Gyorgy Rethy |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
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) | 6.3.3
Source (company - Author) | L.M.Ericsson

Summary | 0006722: Visibility is not taken into account in component compatibility
Description | Currently the visibility (private/friend/public) of component definitions are not handled (not mentioned) in component compatibility rules. The rules has to be extended with visibility.
Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | draft-res-6722.docx (16,667) 07-10-2014 10:19 http://oldforge.etsi.org/mantis/file_download.php?file_id=3092&type=bug

Issue History
Date Modified | Username | Field | Change
10-04-2014 11:52 | Gyorgy Rethy | New Issue |
15-04-2014 13:55 | Jacob Wieland - Spirent | Note Added: 0012038 |
18-06-2014 08:40 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
18-06-2014 08:40 | Gyorgy Rethy | Description Updated | bug_revision_view_page.php?rev_id=31#r31
06-10-2014 16:11 | Gyorgy Rethy | Note Added: 0012237 |
06-10-2014 16:11 | Gyorgy Rethy | Assigned To | => Axel Rennoch
06-10-2014 16:11 | Gyorgy Rethy | Status | new => assigned
07-10-2014 10:19 | Axel Rennoch | File Added: draft-res-6722.docx |
07-10-2014 10:19 | Axel Rennoch | Note Added: 0012248 |
07-10-2014 10:20 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy
07-10-2014 10:20 | Axel Rennoch | Status | assigned => confirmed
08-10-2014 09:30 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
08-10-2014 14:23 | Jens Grabowski | Status | confirmed => resolved
08-10-2014 14:23 | Jens Grabowski | Resolution | open => fixed
08-10-2014 14:23 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
08-10-2014 16:34 | Jacob Wieland - Spirent | Note Added: 0012301 |
08-10-2014 16:34 | Jacob Wieland - Spirent | Status | resolved => feedback
08-10-2014 16:34 | Jacob Wieland - Spirent | Resolution | fixed => reopened
09-10-2014 10:22 | Gyorgy Rethy | Note Added: 0012311 |
09-10-2014 10:22 | Gyorgy Rethy | Status | feedback => assigned
10-10-2014 10:28 | Axel Rennoch | Note Added: 0012346 |
10-10-2014 10:30 | Axel Rennoch | Note Added: 0012347 |
10-10-2014 10:30 | Axel Rennoch | Status | assigned => confirmed
03-11-2014 16:51 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
04-11-2014 12:40 | Jens Grabowski | Note Added: 0012395 |
04-11-2014 12:41 | Jens Grabowski | Status | confirmed => resolved
04-11-2014 12:41 | Jens Grabowski | Resolution | reopened => fixed
04-11-2014 12:41 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
05-01-2015 16:13 | Gyorgy Rethy | Note Added: 0012619 |
05-01-2015 16:13 | Gyorgy Rethy | Status | resolved => closed
05-01-2015 16:13 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06)

Notes

(0012038)
Jacob Wieland - Spirent
15-04-2014 13:55

Could you elaborate on what the problem is? Visibility normally is only interesting on the context-checking level. How does that influence component compatibility rules?

(0012237)
Gyorgy Rethy
06-10-2014 16:11

Take the straighforward approach: visibility has to be the same in the parent and in the child.

(0012248)
Axel Rennoch
07-10-2014 10:19

additional rule added to consider visibility for compatibility

(0012301)
Jacob Wieland - Spirent
08-10-2014 16:34

Sorry, can you please explain what visibility has to do with compatibility. Visibility normally only affects which names I can reference/use. So,if a name is not visible from my point of reference, I cannot use it. What has that to do with component type compatibility.
If a function is defined on a component type which is not visible to me but I know a compatible component type - why should I not be allowed to run the function on that component type?

(0012311)
Gyorgy Rethy
09-10-2014 10:22

STF discussion: componenet type need not be visible at places where a function with a compatible component type in its run on clause is called. Check this and make explicit if not defined yet is clause 8.2.3.1.

(0012346)
Axel Rennoch
10-10-2014 10:28

In 8.2.3.1 restriction d) appears to be sufficient. In addition we have example 5 which addresses such component extension. From this view there is no need for any more change and the CR may be closed.

(0012347)
Axel Rennoch
10-10-2014 10:30

CR do not need any changes and can be closed.

(0012395)
Jens Grabowski
04-11-2014 12:40

8.2.3.1 restriction d)
"A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5)."
And example 5:
EXAMPLE 5: Importing local definitions transitively
module A {
type enumerated MyEnum_Type { enumX, enumY, enumZ}
type record MyRec { integer a, integer b }
type component MyComp { var MyRec v_Rec := { a := 5 } }
}
module B {
import from A all;
modulepar MyEnum_Type px_MyModulePar := enumY;
type component MyCompUser extends MyComp {}
}
module C {
import from B all;
testcase TC() runs on MyCompUser {
if (px_MyModulePar == enumY) {
// the enumerated value enumY is know in C without explicitly
// importing it from A
setverdict(pass)
}
if (v_Rec.a == 5) {
v_Rec.b := v_Rec.a;
// Both the variable name v_Rec and the record field names are
//known in C without
// explicitly importing them from A
setverdict (pass)
}
}
}
should do the job. Thus, no changes need to be implemented in the standard.

(0012619)
Gyorgy Rethy
05-01-2015 16:13

No change is needed in the stanadrd.