Commit 6df65f93 authored by urbant's avatar urbant
Browse files

Several "on-hold" tests resolved and moved to the ATS

parent 7a7ae47d
/*****************************************************************
** @author STF 433
** @version 0.0.1
** @purpose 1:15.6.2, ? shall be returned for mandatory subfields and * shall be returned for optional subfields.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
//on hold till resolution of CR6711
module Sem_150602_ReferencingRecordAndSetFields_003 {
type component GeneralComp { }
type record MyRecordTwo {
integer g1,
MyRecordTwo g2 optional
}
type record MyRecordOne {
integer f1 optional,
MyRecordTwo f2 optional
}
testcase TC_Sem_150602_ReferencingRecordAndSetFields_003() runs on GeneralComp {
var boolean v_matchRes;
var template MyRecordOne m_R1 := {
f1 := 0,
f2 := ?
}
// m_R2.g1 is mandatory, therefore it shall be ?
// m_R2.g2 is optional, therefore it shall be *
var template MyRecordTwo m_R2 := m_R1.f2;
var template(value) MyRecordTwo m_value := {
g1 := 5,
g2 := omit
}
// match against {?, *}
v_matchRes := match(m_value, MyRecordTwo:{m_R2.g1, m_R2.g2});
if (v_matchRes) {
setverdict(pass);
} else {
setverdict(fail, "match against {?, *}");
}
}
control{
execute(TC_Sem_150602_ReferencingRecordAndSetFields_003());
}
}
\ No newline at end of file
/*****************************************************************
** @author STF 433
** @version 0.0.1
** @purpose 1:15.6.2, ? shall be returned for mandatory subfields and * shall be returned for optional subfields.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
//on hold till resolution of CR6711
module Sem_150602_ReferencingRecordAndSetFields_004 {
type component GeneralComp { }
type record MyRecordTwo {
integer g1,
MyRecordTwo g2 optional
}
type record MyRecordOne {
integer f1 optional,
MyRecordTwo f2 optional
}
testcase TC_Sem_150602_ReferencingRecordAndSetFields_004() runs on GeneralComp {
var template MyRecordOne m_R1 := {
f1 := 0,
f2 := ?
}
// m_R2.g1 is mandatory, therefore it shall be ?
// m_R2.g2 is optional, therefore it shall be *
var template MyRecordTwo m_R2 := m_R1.f2;
var template(value) MyRecordTwo m_value := {
g1 := 5,
g2 := omit
}
// match against {?, *} - use dotted notation to cover other expansion thread
var boolean v_matchRes := match(m_value, MyRecordTwo:{m_R1.f2.g1, m_R1.f2.g2});
if (v_matchRes) {
setverdict(pass);
} else {
setverdict(fail, "match against {?, *} - use dotted notation to cover other expansion thread");
}
}
control{
execute(TC_Sem_150602_ReferencingRecordAndSetFields_004());
}
}
\ No newline at end of file
/*****************************************************************
** @author STF 470
** @version 0.0.1
** @author STF 470 (updated by STF 521)
** @version 0.0.2
** @purpose 1:15.8, Ensure that the restrictiveness of parameters template(value)->template(present) is handled correctly.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
// Older versions of the core languate standard didn't allow this type of
// modification because of restriction 15.8.c.
/*
Pro opinion:
Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
Contra opinion
The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
*/
// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check.
// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to
// stricter approach in which case the test should be change to a negative one.
module Sem_1508_TemplateRestrictions_031 {
......
/*****************************************************************
** @author STF 470
** @version 0.0.1
** @author STF 470 (updated by STF 521)
** @version 0.0.2
** @purpose 1:15.8, Ensure that the restrictiveness of parameters template(value)->template(omit) is handled correctly.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
// Older versions of the core languate standard didn't allow this type of
// modification because of restriction 15.8.c.
/*
Pro opinion:
Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
Contra opinion
The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
*/
// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check.
// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to
// stricter approach in which case the test should be change to a negative one.
module Sem_1508_TemplateRestrictions_032 {
......
/*****************************************************************
** @author STF 470
** @version 0.0.1
** @author STF 470 (updated by STF 521)
** @version 0.0.2
** @purpose 1:15.8, Ensure that the restrictiveness of parameters template(value)->template is handled correctly.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
// Older versions of the core languate standard didn't allow this type of
// modification because of restriction 15.8.c.
/*
Pro opinion:
Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
Contra opinion
The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
*/
// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check.
// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to
// stricter approach in which case the test should be change to a negative one.
module Sem_1508_TemplateRestrictions_033 {
......
/*****************************************************************
** @author STF 470
** @version 0.0.1
** @author STF 470 (updated by STF 521)
** @version 0.0.2
** @purpose 1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
// Older versions of the core languate standard didn't allow this type of
// modification because of restriction 15.8.c.
/*
Pro opinion:
Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
Contra opinion
The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
*/
// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check.
// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to
// stricter approach in which case the test should be change to a negative one.
module Sem_1508_TemplateRestrictions_034 {
......
/*****************************************************************
** @author STF 470
** @version 0.0.1
** @author STF 470 (updated by STF 521)
** @version 0.0.2
** @purpose 1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
// Older versions of the core languate standard didn't allow this type of
// modification because of restriction 15.8.c.
/*
Pro opinion:
Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
Contra opinion
The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
*/
// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check.
// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to
// stricter approach in which case the test should be change to a negative one.
module Sem_1508_TemplateRestrictions_035 {
......
/*****************************************************************
** @author STF 470
** @version 0.0.1
** @author STF 470 (updated by STF 521)
** @version 0.0.2
** @purpose 1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
// Older versions of the core languate standard didn't allow this type of
// modification because of restriction 15.8.c.
/*
Pro opinion:
Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
Contra opinion
The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
*/
// The issue is still a problem in TTCN-3:2016 as rules of 15.8 allow runtime (content-dependent) check.
// For that reason, the test seems valid, but there's an active CR7603 on this topic that would lead to
// stricter approach in which case the test should be change to a negative one.
module Sem_1508_TemplateRestrictions_036 {
......
/*****************************************************************
** @author STF 470
** @version 0.0.1
** @purpose 1:15.11, Ensure that concatenations of record of charstrings work when parameterized.
** @verdict pass accept, ttcn3verdict:pass
*****************************************************************/
//on hold till resolution of CR6564
//The syntax used in the test case does appear in the examples and explaining comments, but there are no formal rules that support this notation and explain how it should work.
module Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_014 {
type component GeneralComp { }
type record of charstring RecOfChar;
template RecOfChar m_myRec_par(integer p_num) := {"ABC"} & ? & * length(p_num) & {"EF"};
testcase TC_Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_014() runs on GeneralComp {
var integer v_int := 3;
var template RecOfChar v_recofChar;
v_recofChar :={ "ABC" } & { "Z" } & { "Z" } & { "Z" } & { "EF" };
if (match(v_recofChar, m_myRec_par(2))) {
setverdict(pass);
} else {
setverdict(fail);
}
}
control{
execute(TC_Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_014());
}
}
\ No newline at end of file
/***************************************************
** @author STF 487
** @version 0.0.1
** @purpose 1:16.1.2, Ensure that the IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C)
** @verdict pass accept, ttcn3verdict:pass
***************************************************/
//on hold till resolution of CR7128
/* The following requirements are tested:
* This function converts an UTF-16 universal charstring value to a Little endian octetstring.*/
module Sem_160102_predefined_functions_030 {
type component GeneralComp {
}
testcase TC_Sem_160102_predefined_functions_030 () runs on GeneralComp {
// universal charstring:
var universal charstring v_0 := "ABC";
// predefined function for universal charstring to octetstring conversion:
var octetstring v_encoded := unichar2oct(v_0, "UTF-16LE"); //"UTF-16" little endian, expected value:'0041 0042 0043'O;
var octetstring v_1 := '004100420043'O;
if( match(v_encoded,v_1)
) {
setverdict(pass,"Encoded value for: ",v_0, " is ", v_encoded);
}
else {
setverdict(fail,"encoded value is: ", v_encoded, " expected ", v_1);
}
}
control{
execute(TC_Sem_160102_predefined_functions_030());
}
}
\ No newline at end of file
/***************************************************
** @author STF 487
** @version 0.0.1
** @purpose 1:16.1.2, Ensure that the IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C)
** @verdict pass accept, ttcn3verdict:pass
***************************************************/
//on hold till resolution of CR7128
/* The following requirements are tested:
* This function converts an UTF-32 universal charstring value to a Little endian octetstring.*/
module Sem_160102_predefined_functions_031 {
type component GeneralComp {
}
testcase TC_Sem_160102_predefined_functions_031 () runs on GeneralComp {
// universal charstring:
var universal charstring v_0 := "ABC";
// predefined function for universal charstring to octetstring conversion:
var octetstring v_encoded := unichar2oct(v_0, "UTF-32LE"); //"UTF-32" little endian, expected value:'0000 0041 0000 0042 0000 0043'O
var octetstring v_1 := '000000410000004200000043'O;
if( match(v_encoded,v_1)
) {
setverdict(pass,"Encoded value for: ",v_0, " is ", v_encoded);
}
else {
setverdict(fail,"encoded value is: ", v_encoded, " expected ", v_1);
}
}
control{
execute(TC_Sem_160102_predefined_functions_031());
}
}
\ No newline at end of file
/***************************************************
** @author STF 487
** @version 0.0.1
** @purpose 1:16.1.2, Ensure that the IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C)
** @verdict pass accept, ttcn3verdict:pass
***************************************************/
//on hold till resolution of CR7128
/* The following requirements are tested:
* This function converts an UTF-16 universal charstring value to a Big endian octetstring.*/
module Sem_160102_predefined_functions_032 {
type component GeneralComp {
}
testcase TC_Sem_160102_predefined_functions_032 () runs on GeneralComp {
// universal charstring:
var universal charstring v_0 := "AB";
// predefined function for universal charstring to octetstring conversion:
var octetstring v_encoded := unichar2oct(v_0, "UTF-16BE"); //"UTF-16" Big endian, expected value:'42004100'O;
var octetstring v_1 := '42004100'O;
if( match(v_encoded,v_1)
) {
setverdict(pass,"Encoded value for: ",v_0, " is ", v_encoded);
}
else {
setverdict(fail,"encoded value is: ", v_encoded, " expected ", v_1);
}
}
control{
execute(TC_Sem_160102_predefined_functions_032());
}
}
\ No newline at end of file
/***************************************************
** @author STF 487
** @version 0.0.1
** @purpose 1:16.1.2, Ensure that the IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C)
** @verdict pass accept, ttcn3verdict:pass
***************************************************/
//on hold till resolution of CR7128
/* The following requirements are tested:
* This function converts an UTF-32 universal charstring value to a Big endian octetstring.*/
module Sem_160102_predefined_functions_033 {
type component GeneralComp {
}
testcase TC_Sem_160102_predefined_functions_033 () runs on GeneralComp {
// universal charstring:
var universal charstring v_0 := "AB";
// predefined function for universal charstring to octetstring conversion:
var octetstring v_encoded := unichar2oct(v_0, "UTF-32BE"); //"UTF-32" Big endian, expected value:'42 00 00 00 41 00 00 00'O
var octetstring v_1 := '4200000041000000'O;
if( match(v_encoded,v_1)
) {
setverdict(pass,"Encoded value for: ",v_0, " is ", v_encoded);
}
else {
setverdict(fail,"encoded value is: ", v_encoded, " expected ", v_1);
}
}
control{
execute(TC_Sem_160102_predefined_functions_033());
}
}
\ No newline at end of file
/***************************************************
** @author STF 487
** @version 0.0.1
** @purpose 1:16.1.2, Ensure that the IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C)
** @verdict pass accept, ttcn3verdict:pass
***************************************************/
//on hold till resolution of CR7128
module Sem_160102_predefined_functions_038 {
type component GeneralComp {
}
testcase TC_Sem_160102_predefined_functions_038 () runs on GeneralComp {
//octetstring:
var octetstring v_0 := '004100420043'O;
// predefined function for universal charstring to octetstring conversion:
var universal charstring v_decode := oct2unichar(v_0,"UTF-16LE"); //expected value: ABC
var universal charstring v_1 := "ABC";
if( match(v_decode,v_1)
) {
setverdict(pass,"Decoded value for: ",v_0, " is ", v_decode);
}
else {
setverdict(fail,"encoded value is: ", v_decode, " expected ", v_1);
}