Some information can be obsolete. It was useful when we started designing the tests to attempt to gather ideas about the subject of testing and approach of testing. ================================ Source Operand Complex test specification (guideline of designing the test) Collection of remarks not intended to constitute the facile joined statement. These considerations should be taken into account while designing the Source Operand Complex test. Some of them are applicable in general while designing the ASL tests. All the ASL declarartions allowed by the ASL compiler have to work in compliance with the ACPI specification, in a predictable and convenient for users manner (so, ACPI could be changed as well). Outlined are the subject of testing, the main aspects of it, the main points to be concentrated on while designing the test and the practical steps which should be performed to achieve the worthy coverage of the test. Also the objective difficulties which are on that way are explained. This text is for ourselves in the first order. Allow, some statements to be abstract, non-strict and questionable. Bilieve, the abstraction will be useful. Writing the Operand Complex test is quite complicated (it is not a functional test were you simply verify each feature separately), so after implementing some its part you see some ASL functionality is involved by test repeatedly though you thought about different things. This text is in particular intended to enumerate all the aspects to be verified, and don't furhter hesitate if all them are applied. The intention of the test is to verify all the grammar rules of specifying and delivering operands to operators. This is a wide range of issues which are simpler to understand and embrace given together as a separate particular topic, as a separate approach. Each the particular relevant aspect should be given separately, the approach of how to test it should be designed and then applied to all the ASL operators. Then the next aspect should be taken separately and also verified for all the operators. This would allow to concentrate deeply on each aspect and to observe the coverage provided by the test which would be impossible to do in the contrary case when the per-operator tests each contains all the aspects checkings. All the relevant aspects should be verified for each particular operator (or at least for one member of each group of operators divided according to the considered aspects of delivering operands to operators if only you can found such division to groups). While building the tests we have observed many confirmations of the idea that aspects of delivering operands to operators can work differently for different operators, while being proper for some of them it fails for other. Minimum functionality of operators should be involved there to prove only the fact that operands are delivered to operators correctly. To check functionality of operators is up to other tests. The test should also check that the source values which were referred to as parameters were not corrupted by the execution of the particular operator, which are the situations being in practice revealed by our other tests many times. The test verifies processing of both the valid operands and invalid operands. Building the invalid operand checkings is a simple task - pass operator with the inappropriate type operand and check that the exception occurs. So, below are mostly about the valid operand checkings. The valid operand checkings verify all the legal ways of specifying and delivering operands to ASL operators. The following section describes the essential aspects of that process. Note: some particularities are obsolete due to the change of ACPI specification since that. ESSENTIAL ASPECTS OF OPERAND DELIVERING ======================================= IMAGES All the vatiety of ways specifying the immediate images of ASL objects of all types should be represented. All the types are given in the table 17-20 of ACPI specification: Uninitialized * Integer * String * Buffer * Package * Field Unit Device Event Method Mutex Operation Region Power Resource Processor Thermal Zone * Buffer Field DDB Handle (*) - computational types. The table #1 below shows all the variety of computational type images () - the remained types are mostly used in the invalid operand checkings LOCATIONS The location of the object in the name space relating to the operator where that object is utilized. - statically accessible global object located immediately in the DefinitionBlock - statically accessible declared locally in the current scope - statically accessible declared locally in the surrounding upper scope, (1,2,3,...,LOC_LEVELS levels up) - inaccessible statically, declared locally in the sequence of the calling methods, (1,2,3,...,LOC_LEVELS levels up) Note: all the functionality of all scope generating concepts: DefinitionBlock, Scope, Device, Method, Function, Processor, PowerResource, ThermalZone,... will be verified in the relevant complex tests, not here. REFERENCES References to objects, dereferred then by DeRefOf. References by Index Index(String, Index) Index(Buffer, Index) Index(Package, Index) Index(String, Index, Destination) Index(Buffer, Index, Destination) Index(Package, Index, Destination) DerefOf(Index(String, Index)) DerefOf(Index(Buffer, Index)) DerefOf(Index(Package, Index)) DerefOf(Index(String, Index, Destination)) DerefOf(Index(Buffer, Index, Destination)) DerefOf(Index(Package, Index, Destination)) References by RefOf RefOf(Integer) RefOf(String) RefOf(Buffer) RefOf(Package) DerefOf(RefOf(Integer)) DerefOf(RefOf(String)) DerefOf(RefOf(Buffer)) DerefOf(RefOf(Package)) References by CondRefOf CondRefOf(Integer) CondRefOf(String) CondRefOf(Buffer) CondRefOf(Package) CondRefOf(Integer, Result) CondRefOf(String, Result) CondRefOf(Buffer, Result) CondRefOf(Package, Result) DerefOf(CondRefOf(Integer)) DerefOf(CondRefOf(String)) DerefOf(CondRefOf(Buffer)) DerefOf(CondRefOf(Package)) DerefOf(CondRefOf(Integer, Result)) DerefOf(CondRefOf(String, Result)) DerefOf(CondRefOf(Buffer, Result)) DerefOf(CondRefOf(Package, Result)) Note: it was observed earlier that logical operators didn't cause exceptions when using references. This looks incorrect. Keep attention to that. Dont forget to build the test for it. Note: specification of Reference test contains more exact list. EXPRESSIONS The way how the object is specified for operator in place of operand. - immediate image - ArgX - LocalX - NamedX - expression as such, immediate result of other operators (references are some of operators as well) like this: Operator(Operator(Operator(Operator(...)))) Operator([Operand,]Operator([Operand,]Operator(...))) Depth: 1,2,3,...,EXP_LEVELS - use execution of other Methods as a kind of expressions as well Note: expressions in place of locations for results (Destinations) should be verified in this test as vell, because together with the expressions of operands they can influence each other. Issue: expressions in result, is that possible to use? METHODS - use Methods as elements of expressions - use all kind expressions as parameters to Methods CONVERSION The Implicit Source Operand Conversion functionality (17.2.5.7 Data Type Conversion Rules) should be verified also. The table # 1 below proposes the particular values for to initiate all the variety of Implicit Source Operand Conversion rules. OPERATORS As it was mentioned above, the particular target operator can impact delivering operands to it. Thus, we can't build the test for only one particular operator but should be bent on building the checkings for many (to all is the best) of them or for one member of each group (if manage found division). An aspect can work correctly while delivering operand to one operator but fail while delivering to other. Pay attention to both: - the complete and the reduced forms of operators - the target operators and operators used in expressions MISCELLANEOUS Additional miscellaneous features, particular situations which should be verified. They are descended from the aspects above (as the particular elements of an absolute test (see below)). These notes allow to keep additional attention to them. They look to be a complicated modes for ACPICA. Note: add this aspect with more new complicated checkings. 1. Use the same object more than one time in expressions of operands and destinations: - in expression of one operand of target operator - in expressions of different operands of the target operator - in expression of one operand and the result is stored into the object - in expressions of different operands of target operator and the result is located into the object... - in other words, continue combinations of these features: (one operand)/(some (all) operands) (one operator)/(several operators) (store result in it)/(don't store result in it)... 2. Pass the object of upper level (or even global) accesible statically by ArgX of sequence of calling methods (operand1) and specify the same object as another operand immediately by its NameX (operand2) and use them both in turn (operand1/operand2) as locations for result. 3. Other cases. ABSOLUTE TEST ABSTRACTION ========================= So, all the aspects which can impact delivering operands to operators and thus should be verified are these: Images Locations References Expressions Methods Conversion Operators Miscellaneous The more you mix these aspects the more comprehensive test you have. Each impact generated and verified by test is a function of (N1,N2,N3,N4,N5,N6,N7,N8) parameters. So, to build the total absolut comprehensive test we have to build and verify all the possible combinations of these input states. In this case we will miss nothing and the total coverage of testing the operand delivering will be achieved. To build the test as a simple enumeration and verification of all possible combinations of given above parameters would be the simplest way. Though it would be usually much redundant we would be happy and assured that the total coverage would be actually achieved. Note: what actually is the mix of these (N1-N8) aspects? REALITY, LIMITATIONS OF ACPICA ASL ================================== But there are several limitations of ACPICA ASL which make such simplest and the total coverage assured approach (absolute test) impossible, because they prevent automated processing. About all that below. In consequence of all that, it is remained only to rely on the human factor, intuition and skill to achieve the worthy covarage of the test. Elements of ASL Package could be only Integer, String, Buffer and Package type objects. Other type objects could not be represented immediately in Package. So, it is impossible to collect all the desirable different type objects in Package and then refer them in cycle. We can't pass Method with the Uninitialized object, so these conditions should be also provided by the test as the immediate references to the Uninitialized objects which prevents automated processing as well. One more inconvenience for testing arises from the type conversion functionality. Due to that some type objects could not be representes not only as elements of Package, but also be passed to Method as parameters (Buffer Field, Field Unit, etc..), since they are converted to either Integer or Buffer types in the latter case. As a result, these conditions should be provided by the test immediately also and can not be referred in cycle. The are similar limitations on return from method as well. Some groups of operators (Concatenate; Logical operators) have particularities of Implicit Source Operand Conversion functionality which also restricts uniformity of test for different operators. So, we cant run in cycle all the possible desirable combinations (and aspects) of operands for all the ASL operators, because the ASL limitations dont allow to achieve uniformity of the test building. It is impossible to build the test which simply enumerates all combinations and so achieve the total coverage. One more, such the test will go during the huge boundless time. Thus, it is up to the skill of the designer of the test to choose the main points to be verified in order to build the test which would achieve the worthy coverage for the acceptible time of execution. So, maybe, attempt to divide operators on groups according to the specific of their operands and one operator of each group verify comprehensively, while other members of groups verify in a simplified manner. Do that if the run time of the test increases extremely. So, because of the ASL limitations described above we cant implement the comprehencive test, which would be proven to approximate to the absolute test on coverage. But this specification and the tests adhered to it would allow us to feel ourselves to be on the firm way to achieve the worthy coverage and consider that we have done all needed from our side to achieve the comprehencive tests. So, due to the limitations of ASL above, we refuse attempts to write the common engine which would simplify our work and ensure the high coverage of test. Nevertheless, write and apply where possible the common use methods. Bugs of product revealed must be fixed in real time! Very, very much important! Basing on the proper functionality provided by the target product you achieve more and more deep testing. Once again, it is very much important. Otherwise, the testing turns sour. COMPUTATIONAL DATA IMMEDIATE IMAGES =================================== The table below contains the recommended variety of immediate images for computational types: Integer, String, Buffer, Buffer Field, Field Unit, Package. The table pretends to enumerate all the variety of them. (the Implicit Source Operand Conversion Rules are marked in the table #x with (*). They are ... in this table. For example 8,32:b4,b25,b28 means ...) Table 1. Computational data, immediate images Features of source Operands Features of target Operands | Integer | String | Buffer | ================================================================================== | i1| 0321 | | 25 | 17 | | i2| 9876543210 | | | | I | i3| 0xc179b3fe | | 25,32:i3 | 17,32:i3 | n | i4| 0xfe7cb391d650a284 | | 25,64:i4 | 17,64:i4 | t | i5| 0 | | | | e | i6| 0xffffffff | | | | g | i7| 0xffffffffffffffff | | | | e | i8| 0xabcdef | | | | r | i9| 0xABCDEF | | | | | i10| 0xff | | | | | i11| 0xffffffffff | | | | ---------------------------------------------------------------------------------- | s1| "0321" | 36 | | 28 | | s2| "321" | | | | | s3| "ba9876" | 36,32:s1,s4 | | 28,32:s1,s14, | | s4| "c179b3fe" | 36,64:s1,s5 | | s12 | | s5| "fe7cb391d650a284" | | | 28,64:s1,s14, | | s6| "ffffffff" | 32:s8(exc) | | s12 | S | s7| "ffffffffffffffff" | 64:s8(exc) | | | t | s8| "fe7cb391d650a2841" | 32:s11(exc) | | | r | s9| "9876543210" | 64:s11(exc) | | | i | s10| "0xfe7cb3" | 32:s12(exc) | | | n | s11| "1234q" | 64:s12(exc) | | | g | s12| "" | 32:s13(exc) | | | | s13| " " | 64:s13(exc) | | | | s14| of size 200 bytes | 32:s10(exc) | | | | - | >200, imps, bugs fix | 64:s10(exc) | | | | s15| | | | | | s16| "abcdef" | | | | | s17| "ABCDEF" | | | | | s18| "ff" | | | | | s19| "ffffffffff" | | | | ---------------------------------------------------------------------------------- | b1| B(1){b0} | 6,7 | 8,9 | | | b2| B(2){b0,b1} | | | | | b3| B() {b0,b1,b2} | 6,32:b6 | 8,32:b6,b20 | | | b4| B(2){b0,b1,b2} | 6,64:b6 | 8,64:b6,b20 | | | b5| B(3){b0,b1} | | | | | b6| B(3){b0,b1,b2} | 7,32:b10 | 9,32:b21(exc) | | | b7| B(4){b0,...,b3} | 7,64:b10 | 9,64:b21(exc) | | | b8| B(5){b0,...,b4} | | | | | b9| B(8){b0,...,b7} | | 32:b22(exc) | | | b10| B(9){b0,b1,...,b8} | | 64:b22(exc) | | | b11| B(257){b0} | | | | | b12| B(257){b0,...,b256} | | | | | b13| B(){b0,...,b256} | | | | | b14| B(ArgX){=} | | | | B | b15| B(ArgX){<} | | | | u | b16| B(ArgX){>} | | | | f | b17| B(LocalX){=} | | | | f | b18| B(LocalX){<} | | | | e | b19| B(LocalX){>} | | | | r | b20| B(67){b0,...,b66} | | | | | b21| B(68){b0,...,b67} | | | | | b22| B(ArgX/LocalX==0){} | | | | | b23| B(1){} | | | | | b24| B(5){} | | | | | b25| B(9){} | | | | | b26| B(4){0,...,0} | | | | | b27| B(8){0,...,0} | | | | | b28| B(1){0xff} | | | | | b29| B(4){0xff,...,0xff} | | | | | b30| B(5){0xff,...,0xff} | | | | | b31| B(8){0xff,...,0xff} | | | | | b32| B(9){0xff,...,0xff} | | | | | b33| B(5){0x12,...,0x90} | | | | | b34| B(3){0xab,0xcd,0xef} | | | | | b35| B(3){0xAB,0xCD,0xEF} | | | | | b36| B(200){b0,...,b199} | | | | | b37| B(201){b0,...,b200} | | | | ---------------------------------------------------------------------------------- B | bf1| CF(:31) | 10 | | 11 | u | bf2| CF(:32) | | | | f | bf3| CF(:33) | 10,32:bf1,bf2 | | 11,32:bf3 | f | bf4| CF(:63) | 10,64:bf4,bf5 | | 11,32:bf6 | e | bf5| CF(:64) | | | | r | bf6| CF(:65) | | 32:bf10(exc) | | | bf7| CF(:0) | | 64:bf10(exc) | | F | bf9| CF(:67*8) | | | | i |bf10| CF(:68*8) | | | | e |bf11| CF(:257*8) | | | | l |bf12| BfField,3bytes+{0-16}| | | | d |bf13| BfField,7bytes+{0-16}| | | | ---------------------------------------------------------------------------------- | fu1| F(:31) | 14 | | 15 | F | fu2| F(:32) | | | | i | fu3| F(:33) | 14,32:fu1,fu2 | | 15,32:fu3 | e | fu4| F(:63) | 14,64:fu4,fu5 | | 15,32:fu6 | l | fu5| F(:64) | | | | d | fu6| F(:65) | | 32:fu10(exc) | | | fu7| F(:0) | | 64:fu10(exc) | | U | fu9| F(:67*8) | | | | n |fu10| F(:68*8) | | | | i |fu11| F(:257*8) | | | | t |fu12| Field,3bytes+{0-16} | | | | |fu13| Field,7bytes+{0-16} | | | | ---------------------------------------------------------------------------------- Package ================================================================================== Note: the Implicit Rules were a few changed since that! START WITH THESE OPERATORS (and maybe don't go beyond that) ========================== This is a list of operators which are recomended to be implemented in the first turn. List of operators which should be verified completely (all the aspects of delivering operands to them should be verified). One-parameter operators: - Increment - Decrement - FindSetLeftBit - one of these: ToBuffer, ToDecimalString, ToHexString, ToInteger, ToBCD, FromBCD - Not - SizeOf - Store - CopyObject All other one-parameter operators may be verified partially. Two-parameters operators: - Add - Divide - Multiply - LGreater - ToString - Concatenate - ShiftLeft - Lor - NAnd - XOr All other two-parameters operators may be verified partially. Three-parameters operators: - Mid Six-parameters operators: - Match The tests of operands for the following operators may be implemented separately in their per-operator tests: - If,Elseif - While The positive (not exceptions) tests of operands for the following operators have been done in per-operator tests: - Switch, Case OPERATORS INFO ============== The table below contains the list of operators assigned with digital indexes in the alphabetical order: - one-parameter (25 Operators) - two-parameters (26 Operators) - three-parameters (2 Operators) - six-parameters (1 Operator) Table 2. Operators // ////////////////////////////////////////////////////////////////////////// // // 1 parameter (25 Operators) // // 5 - CondRefOf (any, Result) => Boolean // 6 - CopyObject (any, Destination) => DataRefObject // * 7 - Decrement (int) => Integer // 8 - DerefOf ({ref|str}) => Object // * 11 - FindSetLeftBit (int, Result) => Integer // * 12 - FindSetRightBit (int, Result) => Integer // * 13 - FromBCD (int, Result) => Integer // * 14 - Increment (int) => Integer // * 22 - LNot (int) => Boolean // * 31 - Not (int, Result) => Integer // 32 - ObjectType (any) => Integer // 34 - RefOf (any) => ObjectReference // 35 - Release (mux) // 36 - Reset (evt) // 37 - Return ({any|ref}) // 40 - Signal (evt) // * 41 - SizeOf ({int|str|buf|pkg}) => Integer // * 42 - Sleep (int) // * 43 - Stall (int) // 44 - Store (any, Destination) => DataRefObject // * 46 - ToBCD (int, Result) => Integer // * 47 - ToBuffer ({int|str|buf}, Result) => Buffer // * 48 - ToDecimalString ({int|str|buf}, Result) => String // * 49 - ToHexString ({int|str|buf}, Result) => String // * 50 - ToInteger ({int|str|buf}, Result) => Integer // // 2 parameters (26 Operators) // // 0 - Acquire (mux, wrd) => Boolean // * 1 - Add (int, int, Result) => Integer // * 2 - And (int, int, Result) => Integer // * 3 - Concatenate ({int|str|buf}, {int|str|buf}, Result) => ComputationalData // * 4 - ConcatResTempl (rtb, rtb, Result) => Buffer // * 9 - Divide (int, int, Remainder, Result) => Integer // 15 - Index ({str|buf|pkg}, int, Destination) => ObjectReference // * 16 - LAnd (int, int) => Boolean // * 17 - LEqual ({int|str|buf}, {int|str|buf}) => Boolean // * 18 - LGreater ({int|str|buf}, {int|str|buf}) => Boolean // * 19 - LGreaterEqual ({int|str|buf}, {int|str|buf}) => Boolean // * 20 - LLess ({int|str|buf}, {int|str|buf}) => Boolean // * 21 - LLessEqual ({int|str|buf}, {int|str|buf}) => Boolean // * 23 - LNotEqual ({int|str|buf}, {int|str|buf}) => Boolean // * 24 - LOr (int, int) => Boolean // * 27 - Mod (int, int, Result) => Integer // * 28 - Multiply (int, int, Result) => Integer // * 29 - NAnd (int, int, Result) => Integer // * 30 - NOr (int, int, Result) => Integer // * 33 - Or (int, int, Result) => Integer // * 38 - ShiftLeft (int, int, Result) => Integer // * 39 - ShiftRight (int, int, Result) => Integer // * 45 - Subtract (int, int, Result) => Integer // * 51 - ToString (buf, int, Result) => String // * 52 - Wait (evt, int) => Boolean // * 53 - XOr (int, int, Result) => Integer // // 3 parameters (2 Operators) // // 10 - Fatal (byt, dwd, int) // * 26 - Mid ({str|buf}, int, int, Result) => Buffer or String // // 6 parameters (1 Operator) // // * 25 - Match (pkg, byt, int, byt, int, int) => Ones | Integer // // 1 parameter (5 Operators) // // * 54 - If (int) // * 55 - Elseif (int) // 56 - Switch ({int|str|buf}) // 57 - Case ({int|str|buf|pkg}) // * 58 - While (int) // // (*) - conversion is expected. Operators which are expected // to have conversion of their operands. // // ////////////////////////////////////////////////////////////////////////// STRUCTURE OF TEST ================= 1. Sub-test for aspect 1, verifications for all operators. 2. Sub-test for aspect 2, verifications for all operators. N. Sub-test for aspect N, verifications for all operators. The valid operand checkings and invalid operand checkings should be structurized as different runs - no exceptions should be exercised during the valid operand checkings execution. TABLE OF AVAILABLE MIX OF ASPECTS ================================= 1 2 3 4 5 6 7 8 im loc ref exp mth conv oper misc ---------------------------------------------------------------------------- A | Images | | | | | | | | | B | Locations | | | | | | | | | C | References | | | | | | | | | D | Expressions | | | | | | | | | E | Methods | | | | | | | | | F | Conversion | | | | | | | | | G | Operators | | | | | | | | | H | Miscellaneous | | | | | | | | | ---------------------------------------------------------------------------- Example: A1 means ... Note: you see, it is not ready. PARTICULAR INFORMATION ====================== Buffer Field operators should be passed directly only because ASL doesnt allow to pass Buffer Field type objects without conversion (they are converted to either Integer or Buffer types). Allocate Buffer Fields for both operands from the same buffer (Buffer(20){}). Fill the entire Buffer with the zeros (units), then fill the fields with the units (zeros) and check the contents of the whole Buffer after Operator completion. Results should be written into LocalX, not to involve the "Implicit Result Object Conversion". Perhaps, groups of operators can have the same checkings which can be handled by the same methods (with different benchmark values) so simplifying the designing of tests. But the rest of checkings should be provided by the actions individual for the particular operators. BRIEF RECOMENDATIONS (summary from above) ==================== There should be the most important or usually forgotten things 1. use all type immediate Images 2. use all type Locations 3. use all type References 4. use all type Expressions 5. use Methods in expressions and expressions as parameters to Methods 6. initiate all kind of Implicit Source Operand Conversion 7. exercise all Operators 8. apply recomendations given in Miscellaneous section 9. use full and reduced forms of operators (mean optional Results) 10. use zero length Buffers 11. use uninitialized elements of Packages 12. use non-computational elements of Packages to (initiate/NOT initiate) exceptions during conversion (Match..) 13. use Packages: uninitialized,...,uninitialized, 14. use all operators - ObjectType, SizeOf and LEqual to verify results 15. verify all the obtained results 16. check that the source objects were not corrupted by execution (use all - ObjectType, SizeOf and LEqual) 17. remember about the NULL symbols of strings 18. mix different (all) aspects; the more you mix aspects the more comprehensive test you have 19. add directives into Miscellaneous section and here while increasing your skill of building the test 20. use the same object (and several such objects) (ArgX,LocalX,Name(X)) in different operands and Destination of the same operator 21. use the same object (and several such objects) (ArgX,LocalX,Name(X)) in different operands of different operators of the same expression 22. do the input control (ObjectType, SizeOf, LEqual) of passed values (where needed) 23. check operators for unacceptable types of operands (exception occur) 24. for the acceptable types of operands check particular unacceptable values (exception occur) 25. check that the result is of the same type as the benchmark (use ObjectType, dont be satisfied with LEqual only) 26. the second operands of Logical operators are converted to the type of the first ones; do the checkings which show and confirm that 27. conversion of the second operands of Concatenate operator is performed according to the table; do the checkings which show and confirm that 28. use immediate invocations of operators in place of operands of other operators 29. each operand of several-operands oprerators should be verified 30. before running the operation initialize the destination area with the contr-data (zero expected, take unit; unit expected, take zero); so you see that result does actual change 31. ... --------------------------------------------------------- /* Do the table (or section): ========================== Constants Global named objects Dynamical named objects LocalX ArgX Element of Buffer Element of String Element of Package (DerefOf(Index())) Return of Method Object by reference ... */ /* SEE: update all concerning the Table 17-8 Object Conversion Rules (because specs where changed!): Table 1 file: conversion_table tests:... */ /* See: LocalX/ArgX - different size of source operator Integer, 0xff, 0xffff, 0xffffff, ... - bit of sign of value - all the available symbols (in all positions of 0-9,a-f,A-F) - 32/64 - all unavailable symbols (all except 0-9,a-f,A-F) - combinations of all available/unavailable symbols - B(ArgX){...} - B(LocalX){...} - particular test: Store Buffer/Integer into String which (String) is far longer then Buffer/Integer. The String immage will be reduces. Then attempt to work with the rest of String ouside of the new its contents (behind the null symbol of String). - reference as an element of Package - verify 64-bit values in 32-bit mode */ /* SEE: pseudo accidental test */ /* ???????? what in practice are this mix of aspects ??????????? ??????? see is that possible to use expressions in result ?????? ????? uninitialized data of Package - use them ????? */