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
0008017Part 01: TTCN-3 Core LanguageTechnicalpublic27-04-2021 13:3701-12-2021 08:25
ReporterWolfgang Seka 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008017: Useless restriction for "*"
DescriptionB.1.2.4 restricts the use of "*" to optional fields:
"At the time of matching during a receiving operation, it shall be applied to optional fields of record and set templates only."

It seems that there is a compiler even generating a run time error in case of a mandatory field of a template has assigned a "*", even though in this case, in contrast to other cases, there is no explicit statement to raise an error in ES 201 873-1.
In addition it is not clear what the use of such runtime error is and there seems to be no need to do this.

=> The above restriction is useless from a user's point of view and shall be removed.
TagsNo tags attached.
Clause Reference(s)B.1.2.4
Source (company - Author)     Wolfgang - MCC160
Attached Filesdocx file icon CR8017-1.docx [^] (317,682 bytes) 12-11-2021 13:47
docx file icon CR8017-2.docx [^] (271,889 bytes) 12-11-2021 15:29

- Relationships
related to 0008032closedJens Grabowski BNF links and formatting 

-  Notes
(0015975)
Tomas Urban (developer)
10-09-2021 09:58
edited on: 10-09-2021 10:00

 The statements in this CR are not correct. ES 201 873-1 contains a rule that unambiguously restricts the use of the AnyValueOrNone matching mechanism in B.1.2.4:

The matching symbol "*" (AnyValueOrNone) is used to indicate that any valid value and the omission of the given optional field are acceptable. It can be assigned to templates of any type as a whole or to optional fields of set or record templates.

There are also several notes about this behaviour in the section 15.7.2

In my opinion the CR should be rejected. First, as stated above, there's a clear and unambiguous rule in the core language specification that lists all possible assignment targets for this symbol. Mandatory fields are not listed and therefore cannot be considered to be a valid assignment target. Second, TTCN-3 language design uses this kind of restrictions for detecting possible errors early in the compilation stage or during initialization stage of a testing environment. It also leads to faster execution of the generated code as mandatory field -> template(present) assignments can be always considered safe and the TE doesn't have to verify the content of the source field on the RHS. Third, there are significant differences in semantic rules for field referencing between AnyValue and AnyValueOrNone. The latter one produces errors in most cases which might not be caught by the compiler (in case of runtime-resolved templates). Such errors are completely unexpected for mandatory fields.

However, we could consider to extend the functionality of the present operator so that it doesn't just check if the template fulfils the present restriction, but it could also convert AnyValueOrNone to AnyValue and remove ifpresent extension:

type record MyTypeMandatory {
  integer field1,
  integer field2
}

type record MyTypeOpt {
  integer field1 optional,
  integer field2 optional
}

template MyTypeOpt mw_optional := {
   field1 := *,
   field2 := 10 ifpresent
}

template MyTypeMandatory mw_mandatory := {
  field1 := present(mw_optional.field1),
  field2 := present(mw_optional.field2)
}
// equal to:
// template MyTypeMandatory mw_mandatory := {
// field1 := ?,
// field2 := 10
//}
(0015977)
sekaw (reporter)
10-09-2021 12:52

 First of all I don't understand why (and have no sympathy for) you are claiming that "The statements in this CR are not correct".
The intention of the CR is to remove a - from a user's point of view - useless rule causing a - from a user's point of view - useless and annoying runtime error.
I think, even when you don't like it, it is still a valid request (whether it gets finally agreed is a different story).

So - the main problem in this case is the runtime error, which does not bring any benefit to the user (please let me know, if you can give an example where for this case a runtime error brings a benefit for the user).
=> As there is no common don't-raise-stupid-runtime-errors rule in the TTCN-3 core language, the easiest way seems to be to remove the rule causing the runtime error.

Please note, that the problem may occur mainly as TTCN writers just don't care whether a field is optional or mandatory. They just want to express, that for a particular receive or match operation they don't care about this field at all.
=> new rules or functionalities will not help anything as the user in general is not aware that there is any problem at all.

Of course it may help when a compiler would give a hint at compilation time to make the user aware of the issue.
But with this we would somehow end up in a don't-raise-stupid-runtime-errors rule as the compiler may raise a warning at compilation time to give the TTCN writer the chance for potential improvements of the code, but the compiler shall not raise a runtime error.

Summary: I don't agree to your argumentation and would like to kindly ask the TTCN maintenance STF to think about a solution to avoid such costly and annoying runtime errors.
(0015985)
Jens Grabowski (manager)
10-09-2021 15:42

 Sorry, the Mantis notes prepare and document discussions of the maintenance team. Decisions regarding further study, acceptance or rejection of CRs are made by the whole team. We are very thankful for every comment and clarification during our discussions from outside the team, e.g., reporter or observer, and will consider them during our discussions. The impression that one person can decide is wrong.

For this CR, the TTF discussed the topic in detail and decided to examine the reasons for the introduction of the restriction in more detail. The TTF will then discus ways of relaxing or even removing the restriction.
(0016051)
Jens Grabowski (manager)
10-11-2021 12:18

 STF disussion: Introduce proposal for ".present" operation which yields a template with a present restriction from any template. I.e., "*.present" will be interpreted as "?".
(0016054)
sekaw (reporter)
10-11-2021 13:39

 First of all please note, that we are currently in the middle of a RAN5 meeting so that I'm not able to check all details, but so far I don't see how another operation helps anything in this case:
The major problem is, that "*" may unintendedly be used as parameter for a mandatory field, what is not detected by any tool at compilation time but nevertheless causes a - in my opinion useless - runtime error with some compiler.

=> I don't see how another operation could solve this problem.
NOTE: If we are aware that we are using "*" where "?" would be more appropriate we could easily change it (without any further operation)
Only in cases where in first place it is not known whether a parameter results in "*" or "?" the operation may help, but only if people are aware that they need to use to operation (what most likely is not the case => we still end up with a useless run-time error).
(0016065)
Tomas Urban (developer)
11-11-2021 13:49
edited on: 12-11-2021 12:33

 Unfortunately this is a case of a bad language design. At the moment, TTCN-3 disallows certain content in mandatory fields, but assignments described by Wolfgang are not restricted (i.e. assignment of an unrestricted template to a mandatory field, assignment of an optional field to a mandatory field). This leads to runtime errors which are hard to notice in the design stage and very annoying. TTCN-3 has quite elaborate rules for the present restriction, but these unfortunately do not apply in these cases.

In my opinion, there are just three options how to resolve this:

1. All mandatory fields shall have an implicit present restriction and then the rules specified in 15.8 would apply (according to the table 13). This feature would allow to detect (potential) issues already during compilation time and the test case designer would be forced to use either an explicit present() operation (15.13) to verify the content or the new .present operation for removing optionality from the template, depending on what their intentions are. On the minus side, this will require modification of existing test suites and the existing functionality would be just deprecated, causing only warnings in most compilers working in the default mode for a certain period of time.

2. Allow assignment of matching mechanisms that match omit to mandatory fields without any restrictions as Wolfgang proposed. However, it is not as easy as it might seem. This option would lead to situations when the "omit" symbol could be accidentaly assigned to mandatory fields in the same way as * gets there in the described case. This would make the template unusable (as it can never match) and cause trouble with the valueof operation (which would require a new rule for handling this case). This issue could be prevented by specifically disallowing assignment of the "omit" symbol, but that would mean that the issue with hard-to-detect error would prevail (though in a reduced form). Besides, a new rule should be added to the section for referencing template fields so that AnyValueOrNone is treated as AnyValue if assigned to a mandatory field.

3. The TE could also perform an implicit .present conversion in this case (maybe issuing a compiler warning). Compared to the 2nd solution, nothing would have to be added to the section on template field references, but the issue with omit causing a runtime error would be the same. In addition to that, such an operation would be connected with information loss and people usually prefer explicit approach in these cases.

Unfortunately all approaches have some issues and are more or less backwards incompatible. That makes things quite complicated as tool providers and test developers have different preferences. I propose to discuss it again in the next TTF meeting. I personally think we should not leave it as it is, because the problem is real and affects quite many people. Wolfgang, please feel free to comment, we appreciate your input.
(0016072)
Jens Grabowski (manager)
12-11-2021 09:51

 TTF discussion: After a longer discussion, the TTF will focus on option 1. Option 1 allows to detect the issue at compile or validation time and the .present operation allows explicit conversion. Note, deprecation means that the current features is still available for a certain period of time.

Reason for not supporting Option 2: It would be unclear what will be the contents of a mandatory field in a template, i.e., if it would be present or not. The problem will be shifted to a later assignment.

Reason for not supporting Option 3: Implicit conversion should not be introduced here as all other conversions are explicit.
(0016079)
Tomas Urban (developer)
12-11-2021 13:48

 Resolution uploaded. Please check.
(0016081)
Jacob Wieland - Spirent (reporter)
12-11-2021 15:30

 just a small change as a sentence was grammatically incorrect. please check if my change reflects your intended meaning (in the section about implicit restrictions)

please review
(0016082)
Tomas Urban (developer)
15-11-2021 07:23

 Thanx for the correction.

The last version of the proposal (CR8017-2.docx) can be added to the next version of the core language specification.
(0016128)
Jens Grabowski (manager)
29-11-2021 11:51

 BNF needs to be checked.
(0016134)
Axel Rennoch (developer)
01-12-2021 07:25

 BNF changes in CR 8017 have been implemented in CR0008031+32_Core-Language-without-CR7910-r1.docx
(0016139)
Jens Grabowski (manager)
01-12-2021 08:25

 Implemented

- Issue History
Date Modified Username Field Change
27-04-2021 13:37 Wolfgang Seka New Issue
06-09-2021 09:22 Jens Grabowski Assigned To => Tomas Urban
06-09-2021 09:22 Jens Grabowski Status new => assigned
09-09-2021 09:31 Jens Grabowski Project TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-09-2021 09:58 Tomas Urban Note Added: 0015975
10-09-2021 10:00 Tomas Urban Note Edited: 0015975 View Revisions
10-09-2021 12:52 sekaw Note Added: 0015977
10-09-2021 15:42 Jens Grabowski Note Added: 0015985
08-11-2021 13:14 Tomas Urban Relationship added related to 0008067
08-11-2021 13:15 Tomas Urban Relationship deleted related to 0008067
10-11-2021 12:18 Jens Grabowski Note Added: 0016051
10-11-2021 13:39 sekaw Note Added: 0016054
11-11-2021 13:49 Tomas Urban Note Added: 0016065
11-11-2021 13:49 Tomas Urban Note Edited: 0016065 View Revisions
11-11-2021 13:51 Tomas Urban Note Edited: 0016065 View Revisions
11-11-2021 14:10 Tomas Urban Note Edited: 0016065 View Revisions
12-11-2021 09:51 Jens Grabowski Note Added: 0016072
12-11-2021 12:33 Tomas Urban Note Edited: 0016065 View Revisions
12-11-2021 13:47 Tomas Urban File Added: CR8017-1.docx
12-11-2021 13:48 Tomas Urban Note Added: 0016079
12-11-2021 13:48 Tomas Urban Assigned To Tomas Urban => Jacob Wieland - Spirent
12-11-2021 13:48 Tomas Urban Status assigned => confirmed
12-11-2021 15:29 Jacob Wieland - Spirent File Added: CR8017-2.docx
12-11-2021 15:29 Jacob Wieland - Spirent Status confirmed => assigned
12-11-2021 15:30 Jacob Wieland - Spirent Note Added: 0016081
12-11-2021 15:30 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Tomas Urban
12-11-2021 15:30 Jacob Wieland - Spirent Status assigned => confirmed
15-11-2021 07:23 Tomas Urban Note Added: 0016082
15-11-2021 07:23 Tomas Urban Status confirmed => resolved
15-11-2021 07:23 Tomas Urban Resolution open => fixed
15-11-2021 07:23 Tomas Urban Assigned To Tomas Urban => Jens Grabowski
29-11-2021 11:51 Jens Grabowski Note Added: 0016128
29-11-2021 11:51 Jens Grabowski Status resolved => confirmed
30-11-2021 12:14 Jens Grabowski Assigned To Jens Grabowski => Axel Rennoch
30-11-2021 12:14 Jens Grabowski Status confirmed => assigned
01-12-2021 07:18 Axel Rennoch Relationship added related to 0008032
01-12-2021 07:25 Axel Rennoch Note Added: 0016134
01-12-2021 07:25 Axel Rennoch Assigned To Axel Rennoch => Jens Grabowski
01-12-2021 07:25 Axel Rennoch Status assigned => confirmed
01-12-2021 08:25 Jens Grabowski Note Added: 0016139
01-12-2021 08:25 Jens Grabowski Status confirmed => closed

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